Community
Participate
Working Groups
I20090331-0901. 1. start fresh workspace 2. check out 'org.eclipse.jface.text' tagged 'R3_4' from CVS 3. on 'Target Platform' preference page add a R3.4 target and set it as active 4. wait until build is done ==> everything compiles 5. on 'Target Platform' preference page set 'Running Target' as active target 6. wait until build is done 7. close Package Explorer 8. reopen Package Explorer 9. try to expand the project (click on +) ==> nothing happens The reason why no children are shown is a JavaModelException in org.eclipse.jdt.internal.core.PackageFragmentRoot.getRawClasspathEntry() on line 553. Note that this exception is currently not logged (see bug 271090). If you inspect the Java project using the JavaElement view you will see that the children returned by get children have not been updated by step 6 (e.g. looking at runtime plug-in): JarPackageFragmentRoot: C:\eclipse\drops\R3.4\plugins\org.eclipse.core.runtime_3.4.0.v20080512.jar (does not exist) However, getPath() in PackageFragmentRoot.getRawClasspathEntry() already returns the new path from R3.4: C:/eclipse/drops/I20090331-0901/plugins/org.eclipse.core.runtime_3.5.0.v20090316.jar
Created attachment 130807 [details] Picture showing havoc
In my opinion this issue happens because, sometimes, JavaProject.getPackageFragmentRoots() and JavaProject.getAllPackageFragmentRoots() don't return the same result. The issue is described on http://dev.eclipse.org/newslists/news.eclipse.tools.jdt/msg23983.html and on https://jira.jboss.org/jira/browse/JBIDE-3414 . I have made a workaround for it in JBoss Tools - see https://jira.jboss.org/jira/browse/JBIDE-3414?focusedCommentId=12448646#action_12448646
I'm able to reproduce the problem one out of 10 times. So this is a concurrency issue. Indeed looking at the code, it appears that classpath changes may be lost if the resource delta triggered by the setClasspathContainer(...) is notified in a different thread.
Created attachment 132261 [details] Proposed fix There is no regression test since this is a concurrency issue
>There is no regression test since this is a concurrency issue I'd be happy to verify once the code is in HEAD.
Unfortunately, it seems that this patch introduces a regression in the refactoring tests: java.lang.ArrayIndexOutOfBoundsException: 0 at org.eclipse.jdt.ui.tests.refactoring.ccp.CopyToClipboardActionTest.testEnabled11(CopyToClipboardActionTest.java:523) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:25) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.UITestApplication$1.run(UITestApplication.java:114) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3855) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3476) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2393) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2357) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2209) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:499) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:492) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.pde.internal.junit.runtime.UITestApplication.start(UITestApplication.java:46) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1287) at org.eclipse.equinox.launcher.Main.main(Main.java:1263) However note that I don't see this regression all the time (maybe 3 times out of 5). If someone (Dani, Markus?) who knows this test can isolate the problem, that would be great.
Actually, the refactoring test also fails from time to time with the patch. So this is a red herring. Fix released for 3.5M7
(In reply to comment #7) > Actually, the refactoring test also fails from time to time with the patch. So > this is a red herring. I meant it fails from time to time WITHOUT the patch
Verified that the problem is fixed.
