search

dirs-dev / directories-jvm

a tiny library that provides config/cache/data paths, following the respective conventions on Linux, macOS, BSD and Windows
https://dirs.dev
Mozilla Public License 2.0
237 stars 26 forks source link

real modular version #22

Open pk960 opened 5 years ago

pk960 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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

xenoterracide commented 2 weeks ago

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?