Support Java 9 JPMS about ultralight-java HOT 5 CLOSED

Interesting report. Would it be possible to just compile in a module info while still keeping the main bytecode level 8 and not renaming the packages?

from ultralight-java.

@hdecarne we do have a hard requirement on the java 8 target level for our own projects, however, I still think building with up-to-date java with a proper module-info is probably a better solution than just adding the Automatic-Module-Name attribute.
It should be possible to build multi-release Jars (https://openjdk.java.net/jeps/238) (maintaining Java 8 bytecode level in the root). Releasing different Jars altogether for Java 9+ would also be a reasonable approach, I guess.

The renaming of the databind package to comply with JPMS module naming rules should be fine (although we should wait for @Janrupf s ok on that).

If you wanna try and set that up properly, go ahead, we will gladly accept your pull request 👍

from ultralight-java.

@Janrupf adding a module-info would require java 9+ for compiling. The doubled package name is an issue in any case for JPMS. JPMS expects a 1:1 relationship between module and package (because the visibility is assigned to this relationship and allowing two modules with the same package would open a backdoor).

@zortax I suggested the Automatic-Module-Name approach to be able to keep the source/bytecode at the current level. A multi-release or a multi-jar approach is a whole different beast from my point of view. It will require two different java tool sets for development and increase the build complexity. If still desired I would investigate the multi-jar or variant approach as suggested here https://blog.gradle.org/mrjars. To avoid the bloated MR jar and to avoid possible issues with all kinds of "older" build tools, IDEs etc. which are struggling with the MR jar complexity.

from ultralight-java.

Using gradle it would not be an issue to compile the main source with Java 8 target and then just put in a Java 9+ compiled module-info. HOWEVER, if this does not solve the issue anyway, then renaming the packages is fine.

So ok given, lets rename the packages, makes technically more sense anyway. 👍

from ultralight-java.

@Janrupf yeah the naming issue doesn't really have to do anything with the target level, they just have to have different names as long as we wanna consider them separate modules...

@hdecarne I think you could either set it up properly with a separate toolchain and MR jars which I would still prefer (if the gradle setup is done right I don't think you would run into issues while building locally even if just targetting java 8), but I guess your original proposal is fine as well for now. So go ahead and PR the needed changes (unless you want to wait another week or so till I find some time for it :P)

from ultralight-java.