Community
Participate
Working Groups
Some of our tests refer to modules like java.xml.ws.annotation which have been removed in 11. These tests need to be rewritten, even though there is no easy solution to permanently refer to a JDK module that is deprecated for removal :(
Ref: http://download.eclipse.org/eclipse/downloads/drops4/I20181002-1800/testresults/html/org.eclipse.jdt.core.tests.compiler_ep410I-unit-cen64-gtk3-java11_linux.gtk.x86_64_11.html see: Deprecated9Test.testBug533063_1 Ref: http://download.eclipse.org/eclipse/downloads/drops4/I20181002-1800/testresults/html/org.eclipse.jdt.core.tests.model_ep410I-unit-cen64-gtk3-java11_linux.gtk.x86_64_11.html see: ModuleBuilderTests.testBug526054
http://download.eclipse.org/eclipse/downloads/drops4/I20181003-2215/testresults/html/org.eclipse.jdt.core.tests.model_ep410I-unit-cen64-gtk3-java11_linux.gtk.x86_64_11.html see: AttachSourceTests.testModule2 Uses module oracle.net, which is not included in OpenJDK.
New Gerrit change created: https://git.eclipse.org/r/132521
(In reply to Eclipse Genie from comment #3) > New Gerrit change created: https://git.eclipse.org/r/132521 attempt to fix ModuleBuilderTests.testBug526054() started like routine business, but the boomerang hit me on the back of my head, as another incarnation of bug 466299 (which I had intended to look into for 4.10 anyway). What happened: tests failed, not when running the modified test in isolation but when running the following slice of ModuleBuilderTests: {"testDefaultRootModules", "testBug522503", "testBug522671", "testBug526054"}. Debugging this, I noticed that module jdk.rmic was found via a JrtPackageFragmentRoot, whose parent was the deleted project "util" from the previous test. IIRC, things went south during ClassFile.getJarBinaryTypeInfo(), when we call javaProject.getClasspathEntryFor(getPath()), which throws JavaModelException, thus causing the caller ClassFile.existsUsingJarTypeCache() to simply & silently answer null. This in its own right looks like a bad bug. Looking at the problem and before realizing the close similarity to bug 466299 I invented pretty much the same strategy: to make equals/hashCode smarter, so that we can distinguish the same root with different properties. Where bug 466299 speaks of external annotations, here we speak of an "add-exports" attribute. So, to generalize over both usecases, it is tempting to simply include the extra attributes from the corresponding classpath entry into equals/hashCode. This theoretically brings the same risk as discussed in bug 466299 (just that right now I'm doing my tricks only in JrtPackageFragmentRoot, not the good old JarPackageFragmentRoot). To get some more data about this risk, I instrumented my implementation: if the root is created before the project's classpath has been resolved (i.e., when creating a PFR handle from a project handle), then any use of equals() or hashCode() will throw a RuntimeException. With this setup into RunAllJava9Tests: green. Next, asking Jenkins for a comment...
One more idea: IF getHandleFromMemento() needs fixing to avoid the conflict of equals/hashCode before resolving the project's classpath, THEN we might get away by simply including the extra attributes into the handle, so that those can be reconstructed from a handle. This could actually get us out of jail ...
(In reply to Stephan Herrmann from comment #4) > To get some more data about this risk, I instrumented my implementation: if > the root is created before the project's classpath has been resolved (i.e., > when creating a PFR handle from a project handle), then any use of equals() > or hashCode() will throw a RuntimeException. With this setup into > RunAllJava9Tests: green. > > Next, asking Jenkins for a comment... From history, we have seen new issues come up in a user environment (in this particular area) while our tests ran just fine. So I will be wary of concluding that a green is all fine. (In reply to Stephan Herrmann from comment #5) > One more idea: IF getHandleFromMemento() needs fixing to avoid the conflict > of equals/hashCode before resolving the project's classpath, THEN we might > get away by simply including the extra attributes into the handle, so that > those can be reconstructed from a handle. This could actually get us out of > jail ... +1 to this.
Thanks for you comments, Jay. (In reply to Jay Arthanareeswaran from comment #6) > (In reply to Stephan Herrmann from comment #4) > > To get some more data about this risk, I instrumented my implementation: if > > the root is created before the project's classpath has been resolved (i.e., > > when creating a PFR handle from a project handle), then any use of equals() > > or hashCode() will throw a RuntimeException. With this setup into > > RunAllJava9Tests: green. > > > > Next, asking Jenkins for a comment... > > From history, we have seen new issues come up in a user environment (in this > particular area) while our tests ran just fine. So I will be wary of > concluding that a green is all fine. I totally agree. That's why I wrote "comment", not "proof of correctness" or such :) > (In reply to Stephan Herrmann from comment #5) > > One more idea: IF getHandleFromMemento() needs fixing to avoid the conflict > > of equals/hashCode before resolving the project's classpath, THEN we might > > get away by simply including the extra attributes into the handle, so that > > those can be reconstructed from a handle. This could actually get us out of > > jail ... > > +1 to this. Great, I'll try that strategy in a next patch set. Since this is growing beyond the original JDK 11-related task, I'll move this development to bug 466299.
(In reply to Eclipse Genie from comment #3) > New Gerrit change created: https://git.eclipse.org/r/132521 I once more changed my mind and uploaded a minimal fix here as patch set #3 Reason: I had thought that multiple projects with different add-exports regarding the same JRT would exhibit the underlying bug, but failed to demonstrate this. Instead for the immediate issue a minimal fix for the following observation suffices: (In reply to Stephan Herrmann from comment #4) > What happened: tests failed, not when running the modified test in isolation > but when running the following slice of ModuleBuilderTests: > {"testDefaultRootModules", "testBug522503", "testBug522671", > "testBug526054"}. > Debugging this, I noticed that module jdk.rmic was found via a > JrtPackageFragmentRoot, whose parent was the deleted project "util" from the > previous test. IIRC, things went south during > ClassFile.getJarBinaryTypeInfo(), when we call > javaProject.getClasspathEntryFor(getPath()), which throws > JavaModelException, thus causing the caller > ClassFile.existsUsingJarTypeCache() to simply & silently answer null. > This in its own right looks like a bad bug. Catching this JavaModelException right there reduces the damage to just not being able to use an external annotation path, and succeeds to compile in all other regards. This change should be done regardless of the more general question of caching and identity.
Gerrit change https://git.eclipse.org/r/132521 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=bcd6c4d80d66085378212b006e60707c11391c1a
(In reply to Eclipse Genie from comment #9) > Gerrit change https://git.eclipse.org/r/132521 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=bcd6c4d80d66085378212b006e60707c11391c1a Released the simple fix (comment 8) for 4.10 M3 With this ModuleBuilderTests.testBug526054 should be good for JDK 11+ Additional test demonstrates that we are indeed able to interpret different add-export settings for the same JRT-module even during the same full build.
New Gerrit change created: https://git.eclipse.org/r/132794
(In reply to Eclipse Genie from comment #11) > New Gerrit change created: https://git.eclipse.org/r/132794 re-writes this guy: (In reply to Stephan Herrmann from comment #2) > see: AttachSourceTests.testModule2 > Uses module oracle.net, which is not included in OpenJDK. in two variants: - testModule2(): skip if oracle.net cannot be resolved to a module - testModule2b(): project with minimal incomplete src.zip I verified that testModule2b() without the fix from bug 532733 produces the original failure.
Gerrit change https://git.eclipse.org/r/132794 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=a5bf25c4133dbe77906073141ef6175680eec0b9
New Gerrit change created: https://git.eclipse.org/r/132799
Gerrit change https://git.eclipse.org/r/132799 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=2694f7535100af1572684864d4c954a7360151ab
Tests mentioned in comment 1 and comment 2 succeed as of https://download.eclipse.org/eclipse/downloads/drops4/I20181121-1800/testResults.php Remaining failure but for a different reason: bug 541453
