-
-
Notifications
You must be signed in to change notification settings - Fork 270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multi-release jar for jdk11+ missing #237
Comments
Uhm, modularity is a little beyond my knowledge currently, but I have done some module-related work on the upcoming 6.0.0 release in the develop branch. I'm close to releasing it, would you mind trying a snapshot of that to see if it meets your requirements? Otherwise, I'm happy to work with you to make it Java9+ compatible. |
I will try that out. It is not so complicated at all you have just create a module-info.java(content is in my first post) in the root of the source folder and compile it with Option -release 8 and afterwards again with -release 11 for java9+. So you have inside the source folder another source folder for java 9+ which includes just the module-info.java. The rest of the code remains as it is. But if you want to switch to java 9+ for the whole lib than create the module-info.java in the root folder and compile with java 9+ normally and you have the lib ready. You can have a look here for more details: https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html |
Ok, so multireleases is something mostly useful for the library maintainers: they can leverage JDK functions that are not available in earlier JDKs and then release multiple versions of a class file in a single jar. My question now is, why do you need this?
I was under the impression that the module system is backwards compatible, split packages notwithstanding. Why would I need two releases? Personally I'm not interested in maintaining two code bases. |
Yes and no. The format of the module-info.java is only understand by a compiler greater than java 9. If you create the module-info.java and compile it with java 8 you will get errors. This is the only reason for the multirelease jar files. The multi-release jar prevents you from creating two jar files (one for java8 and one for java9) with two code bases. Which JDK are you using to build the lib ? For the reason above multi-release jar is the solution. |
In the evening I will try it out and let write you what in the pom.xml must be changed and which file to place in which directory to archive all this above. |
I have tried to commit but I think it was not successfully. Please can you use the following maven plugin (readme explains that in more details): But you have to compile with java 9 at least. If you use java 11 you have to use additionally libs such as java.xml (was removed in java 11). src/main/java-mr/9/module-info.java with the following content:
|
I'm still not clear on the issue here. What problem are we solving? Why are you unable to use the library as-is? Newer JDK's should be backwards compatible with legacy jars, with the exception of split packages and J2EE modules. |
I have now commit a working version which is usable with java9+ and has a minimal module-info.java included. For that I had to add some dependend jars and change the packaging goal from jar to multi-release-jar. At last I had to add two properties <maven.compiler.source>1.8</maven.compiler.source> I tried to commit but had no right to commit and therefor as attachment the files. Have a look on it and see if that is ok for you. |
@lanthale, you are focusing on the solution, while I'm still trying to understand the problem (or rather I fail to see a problem to begin with). So if you could please help me understand the problem if there really is one, then maybe we can move on to a solution. |
Sorry I was too fast. For a java-ee app on an application server this is not a problem, but for a desktop app it is. So the files I added before are just adding the necessary information so that the lib is a valid named module with a defined interface for java beyond 9 and that the lib is in parallel useable under java 7 / 8. Hopefully that clarified the issue a bit. |
You can commit on a fork of this repo and then file a Pull Request to merge your changes into this repo. I would greatly appreciate some help with this. Also notice some work is going on here as well to fix the Automatic-Module-Name. |
I just merged a pull request that fixes the module names. I hope to work on the multirelease item now. One question, the requires/exports lines in module-info.java, is that manual work? Because that sounds aweful. Or did you generate that somehow? |
@bbottema You can generate it with |
I'm using 6.5, and cannot compile using java 15: java: module org.simplejavamail reads package org.simplejavamail.internal.modules from both org.simplejavamail and org.simplejavamail.core |
Hi, same problem here with release 7.0.0 and java 17 |
I am using the lib for a javafx application which I have ported from javafx8 to javafx11 and openjdk 11.
In order to use the lib I had to modularize the lib myself and therefore the question if it is possible to get a multi-release jar which can be used in java8 and java 9+ ?
Here is my config to use the lib (I have used moditec to modularize the lib):
The text was updated successfully, but these errors were encountered: