Community
Participate
Working Groups
20020510 First steps with ClasspathContainers. create .classpath <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path=""/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="var" path="JRE_LIB" rootpath="JRE_SRCROOT" sourcepath="JRE_SRC"/> <classpathentry kind="output" path=""/> </classpath> In the build path wizard, want to know if the container can resolve (exists) and want to get the container description. getClasspathContainer(classPathEntry, currProject) -> JME It might be because JRE_LIB is on the classpath too. But as I just wanted to get the description, this exeption is too much. STACK Java Model Exception: Core Exception [code 977] Name collision. at org.eclipse.jdt.core.JavaCore.getClasspathContainer (JavaCore.java:402) at org.eclipse.jdt.internal.ui.wizards.buildpaths.BuildPathsBlock.getExistingEntrie s(BuildPathsBlock.java:339) at org.eclipse.jdt.internal.ui.wizards.buildpaths.BuildPathsBlock.init (BuildPathsBlock.java:293) at org.eclipse.jdt.internal.ui.preferences.BuildPathsPropertyPage.createWithJava (BuildPathsPropertyPage.java:75) at org.eclipse.jdt.internal.ui.preferences.BuildPathsPropertyPage.createContents (BuildPathsPropertyPage.java:65) at org.eclipse.jface.preference.PreferencePage.createControl (PreferencePage.java:201) at org.eclipse.jface.preference.PreferenceDialog.showPage (PreferenceDialog.java:906) at org.eclipse.jface.preference.PreferenceDialog.selectSavedItem (PreferenceDialog.java:596) at org.eclipse.jface.preference.PreferenceDialog.createContents (PreferenceDialog.java:262) at org.eclipse.jface.window.Window.create(Window.java:275) at org.eclipse.ui.dialogs.PropertyDialogAction.run (PropertyDialogAction.java:156) at org.eclipse.jface.action.Action.runWithEvent(Action.java:590) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:407) at org.eclipse.jface.action.ActionContributionItem.handleWidgetEvent (ActionContributionItem.java:361) at org.eclipse.jface.action.ActionContributionItem.access$0 (ActionContributionItem.java:352) at org.eclipse.jface.action.ActionContributionItem$ActionListener.handleEvent (ActionContributionItem.java:47) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:75) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:637) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:1432) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:1221) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1062) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1045) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:739) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:420) at EclipseRuntimeLauncher.main(EclipseRuntimeLauncher.java:16)
This exception was originally thrown in the code of the registered container initializer. I think we should have the container initialization directly throw a JavaModelException (API change) instead of a CoreException, thus the stack trace would read much better.
The exception is indeed raised due to the fact that some project have a duplicate reference to rt.jar. I agree that the exception is too harsh in this scenario. We have had the same problem with cp variables for a year, and nobody has complained so far. We might want to revisit this scenario post 2.0 ? Or maybe the #veriy code when setting new CP should not validate the CP if only performing an update (reusing similar classpath).
Fixed
To give more info on the reason of this bug report: I was thinking about how container entries should be rendered in the UI? First thought that the description of IClasspathContainer should be used. The problems with that are the bug report below and also the fact that this can force a plugin load (however, the plugin would be loaded soon anyway). A alternative solution would be to have a description string at the initializer config element. Advantage is that this prevents plugin load. Drawback is that it can only be a general description about the container. I can imaging that a precise string like (JRE - 1.4) would be helpful. I don't know how the fix that you just released looks like. But if there are still possible validation exceptions on getClasspathContainer, I would suggest to add a getClasspathContainerDescription to JavaCore that would not care about duplications ect.
