real modular version

[pk960]

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]

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]

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]

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).