Community
Participate
Working Groups
JEP 238 talks about extending the JAR format to allow multiple-java-release specific versions of class files in a single file, called multi-release JAR aka "MRJAR". The key here is "multiple-java-release". So, if we were to support this, the compiler should read the version of class depending on the Execution Environment assigned to that specific project and in the absence of version specific class, should fallback to the archive root. The multi release is recognized by the presence of the following attribute in the MANIFEST file: Multi-Release: true The MRJAR can also host multiple version of the same module. More info here: http://openjdk.java.net/jeps/238
As you say "read": am I right that *creating* a MRJAR can be done directly in JDT/UI (wizard) without further support by JDT/Core?
(In reply to Stephan Herrmann from comment #1) > As you say "read": am I right that *creating* a MRJAR can be done directly > in JDT/UI (wizard) without further support by JDT/Core? IIRC, currently JDT UI doesn't use any code from Core to export to a JAR. So thought we might continue with the same approach.
(In reply to Jay Arthanareeswaran from comment #0) > JEP 238 talks about extending the JAR format to allow multiple-java-release > specific versions of class files in a single file, called multi-release JAR > aka "MRJAR". The key here is "multiple-java-release". > > So, if we were to support this, the compiler should read the version of > class depending on the Execution Environment assigned to that specific > project and in the absence of version specific class, should fallback to the > archive root. my understanding or MRJARs is that the compiler must always compile against the 'root' version of the class irregardless of the execution environment of the specific project. I am pretty sure javac never looks inside the META-INF/versions folder for any classes to compile against.
(In reply to Thomas Watson from comment #3) > my understanding or MRJARs is that the compiler must always compile against > the 'root' version of the class irregardless of the execution environment of > the specific project. I am pretty sure javac never looks inside the > META-INF/versions folder for any classes to compile against. Don't pay attention to me :) I re-read the JEP 238 and it does say this: The Java compiler (javac), via the underlying JavacFileManager and ZipFileSystem APIs, must read selected versions of class files as specified by the -target and -release command-line options. The tools javah, schemagen, and wsgen will leverage the underlying changes to JavacFileManager and ZipFileSystem.
JUnit 5.1 has added a multi-release JAR org.junit.platform.commons_1.1.0.v20180327-1502.jar which is present in build I20180402-2000. It has a separate folder for version 9. Not sure if compiler already reads the correct version of the files based on the project level.
(In reply to Noopur Gupta from comment #5) > JUnit 5.1 has added a multi-release JAR > org.junit.platform.commons_1.1.0.v20180327-1502.jar which is present in > build I20180402-2000. It has a separate folder for version 9. > > Not sure if compiler already reads the correct version of the files based on > the project level. This happens only for JRT images as of now. Shouldn't be hard to implement them for JAR files too, assuming the archive structure is straight forward.
(In reply to Jay Arthanareeswaran from comment #6) > (In reply to Noopur Gupta from comment #5) > > JUnit 5.1 has added a multi-release JAR > > org.junit.platform.commons_1.1.0.v20180327-1502.jar which is present in > > build I20180402-2000. It has a separate folder for version 9. > > > > Not sure if compiler already reads the correct version of the files based on > > the project level. > > This happens only for JRT images as of now. Shouldn't be hard to implement > them for JAR files too, assuming the archive structure is straight forward. Something for 4.8?
Created bug 533401 for UI support. Our previous stand for this feature was - it is too much work for too little. I can take this up if there's a significant need for this.
(In reply to Jay Arthanareeswaran from comment #8) > Created bug 533401 for UI support. Our previous stand for this feature was - > it is too much work for too little. I can take this up if there's a > significant need for this. Not at the moment.
Just to mention that somewhere : LWJGL used multi-release jar files to solve some issues with java 9. Eclipse seems to be unable to find the module-info.java located in a such jar, which lead to different behaviours with other tools. https://github.com/LWJGL/lwjgl3/issues/385#issuecomment-383046841
New Gerrit change created: https://git.eclipse.org/r/121632
Ok, now I'm curious: is there any chance this commit will be merge for photon release ?
Gerrit change https://git.eclipse.org/r/121632 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=18cb8c18a0ece00d59fe97c8d820c8be6145f1c5
The fix is now released. I also addressed some issues with the current implementation of --release option along with the patch. Aurélien, please take a moment to try out the next I build and let us know if it works for your scenario.
New Gerrit change created: https://git.eclipse.org/r/122291
(In reply to Eclipse Genie from comment #15) > New Gerrit change created: https://git.eclipse.org/r/122291 The last fix left some regression as seen in the last build's test failures. This patch addresses those. http://download.eclipse.org/eclipse/downloads/drops4/I20180507-0810/testresults/html/org.eclipse.jdt.compiler.tool.tests_ep48I-unit-cen64-gtk3-java9_linux.gtk.x86_64_9.html
Gerrit change https://git.eclipse.org/r/122291 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=8df02ebc7fde26fb9a3e7f4ba4730fef2349f133
New Gerrit change created: https://git.eclipse.org/r/122310
(In reply to Eclipse Genie from comment #18) > New Gerrit change created: https://git.eclipse.org/r/122310 This fixes the typos in the --release options in the compiler.apt interface. Clearly shows this interface has not been tested for the option. Will add more tests soon. Thanks Vikas for pointing out.
Gerrit change https://git.eclipse.org/r/122310 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=7e9706d5565db75316903fbef2d65c3ba40682ff
Created attachment 273967 [details] Test project with LWJGL gradle eclipse; gradle build This still doesn't work for my use case. The module-info.java of LWJGL still seems to not be seen by Eclipse. Maybe I'm doing something wrong, but I'm still able to build it with gradle.
(In reply to Aurélien Mora from comment #21) > This still doesn't work for my use case. The module-info.java of LWJGL still > seems to not be seen by Eclipse. Maybe I'm doing something wrong, but I'm > still able to build it with gradle. Ah, my bad. I didn't pay attention to the point of "module-info.java". The changes that went in now were specifically for binaries. I need to read up more on how we want to handle multi release source files.
Ok. So maybe we should open a new ticket for this topic ?
(In reply to Aurélien Mora from comment #23) > Ok. > So maybe we should open a new ticket for this topic ? Yes, please. And if possible, please include the Jar you mentioned in comment #10.
New ticket: https://bugs.eclipse.org/bugs/show_bug.cgi?id=534624
