Community
Participate
Working Groups
Build ID: v20070514 In the .project file, the order of arguments to build commands and linked resources is dependent on the JREs implementation of String.hashCode(). It might also make sense to sort referenced projects by name and natures by id rather than expecting all clients to worry about such things. Correcting this will improve team interactions.
The implementation of String.hashCode does not depend on the VM: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html#hashCode()
OK, so it isn't the hashCode specifically, but other things like the size of a HashMap and the insertion order will affect the order entries are returned by an iterator leading to orderings in the .project file. There are a few places in the CDT where a project's natures or referenced projects may be reordered: IProjectDescription.setNatureIds ->org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.checkBuildSystemChange(IProjectDescription, ICConfigurationDescription, ICConfigurationDescription, IProgressMonitor) ->org.eclipse.cdt.managedbuilder.internal.dataprovider.ProjectConverter.convertProject(IProject, IProjectDescription, String, ICProjectDescription) IProjectDescription.setReferencedProjects ->org.eclipse.cdt.internal.core.model.SetPathEntriesOperation.updateProjectReferencesIfNecessary() ->org.eclipse.cdt.internal.core.settings.model.CProjectDescriptionManager.checkProjectRefChange(IProjectDescription, ICConfigurationDescription, ICConfigurationDescription, IProgressMonitor) I may make sense to have a separate bugzilla for these, but there isn't any semantic meaning to the order of either of these properties of a project so it makes sense to me that the core should ignore the order specified and always answer the arrays in a consistent order and serialize them consistently. The public API in ICommand to manage arguments does not allow order to be specified so the onus should be on the core to serialize it reasonably. Copying or cloning a HashMap reverses the order of elements in the buckets. The map is copied once when returned via getArguments() and copied again when the arguments are updated by setArguments(Map). If a client copies the map an odd number of times in between those two calls, the .project would be reordered even if no real changes occurred (to command arguments).
Nature Ids: The order is meaningful here, as mentioned in IProjectDescription.setNatureIds() API. Project references: We don't know what clients might be using these references for, and they may rely on the specified order (for example JDT used this in the past for ordering entries on the Java compiler's build path). In any case, changing the order now would have no benefit, and would cause everyone in the world to have an outgoing change on their .project file. Hash maps: Agree this is a bug, and it turns out we already have a bug for it (bug 177148) Note, we do perform a test on the project description to check if there are real changes before writing it out to disk (ProjectDescription.hasPublicChanges). So, the .project is only written when there are real changes to the description. Unless we have a bug in that comparison code I don't think this will improve SCM interactions. *** This bug has been marked as a duplicate of bug 177148 ***
