Skip to content
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

real modular version #22

Open
pk960 opened this issue Aug 16, 2019 · 6 comments
Open

real modular version #22

pk960 opened this issue Aug 16, 2019 · 6 comments

Comments

@pk960
Copy link

pk960 commented Aug 16, 2019

Hello,
Because I want to use your jar with jlink, having an automatic-module-name isn't enough, a module-info.java file is necessary.
However, it means compiling with java 9, thus droping the java 6 support, except if you create a multi-release jar or use another branch for java 9.
I have found no way with the configured version of sbt, neither to compile a module-info.java file, nor to create a multi-release jar. But sbt isn't a build tool i'm used to.
For the moment, I have created a real modular version in my fork of your repository, using maven to build.
Do you see a better solution ?

@soc
Copy link
Collaborator

soc commented Aug 16, 2019

I think creating a multi-release jar might make sense, as the next release I'm targeting is the one in which Project Panama ships.

Question is whether just creating the module-info.class file locally, committing it and adding it to the jar file during the build process would be "good enough", because (as most things in Scala) https://github.com/sbt/sbt-multi-release-jar is pretty much dead and unmaintained.

@pk960
Copy link
Author

pk960 commented Aug 16, 2019

Just putting a module-info.class into a jar produced with an earlier version of java seems to be good enough.

According to https://techbeacon.com/app-dev-testing/legacy-developers-guide-java-9, it should work: "The information in module-info.class is only visible when the JVM is looking for it, which means that modularized JAR files are treated like ordinary JAR files when running on older versions of Java (assuming the code has been compiled to target an earlier version of Java. Strictly speaking, you’d need to cheat a little and still target module-info.class to Java 9, but that’s doable). "

I have made some tests with your jar where I have added - at the root - a module-info.class built from https://github.com/pk960/directories-jvm/blob/master/src/main/java/module-info.java. I was able to use it without problem with jlink and also with a version 8 jvm.

However, I think that adding the module-info.class under META-INF/versions/9 rather than under the root is probably better for the future.

@soc
Copy link
Collaborator

soc commented Aug 17, 2019

Ok, great, then let's go this route.

Though I would do this after I migrated to the organization (I registered dirs.dev earlier that I want to use instead of soc.github.io).

@xenoterracide
Copy link

I like this but, do people still need java 8 support? the latest android support is java 17, and java 8 was EOL in 2019.

@soc
Copy link
Collaborator

soc commented Nov 7, 2024

The next version will require Java 22, fwiw...

@xenoterracide
Copy link

22? Oof. I think I saw why though. I should probably double check the current requirement... As I'm trying not to go over java 11 for what I'm currently doing.

On that note have you considered using semver instead of just an incrementing integer?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants