Proper module-info.java

[driverpt]

Is your feature request related to a problem? Please describe.

We are trying to migrate to JDK 17 and we're having issues regarding Jigsaw

java: package com.launchdarkly.sdk.server.interfaces does not exist

The only module-info.class exposed in the jar is

module com.google.gson {
  requires java.sql;
  requires jdk.unsupported;

  exports com.google.gson;
  exports com.google.gson.annotations;
  exports com.google.gson.reflect;
  exports com.google.gson.stream;
}

Describe the solution you'd like A proper module-info.java

Describe alternatives you've considered N/A

Additional context N/A

[eli-darkly]

Thanks for bringing this up. We've been slow in getting to Java 17 compatibility updates, and we need to give some more thought to how to get the module info right while still working correctly with older Java versions as well. We'll update this issue as we get further with this work.

[driverpt]

For Java 17 all you need is module-info.java. Jigsaw is now mandatory

[eli-darkly]

Right, we need it but as you saw in your PR, the question is how to correctly update our somewhat complicated Gradle build to make sure it is actually generated correctly. Gradle's default behavior works fine for simpler projects, but we're doing a lot of extra post-processing to embed dependencies, modify OSGi manifests, etc., which can interfere.

[driverpt]

There's something in the Shadow Jar task that is generating a module-info.class with improper data. So far thin doesn't works properly, but we're using our own dependencies. Jigsaw is pretty much like OSGi

[eli-darkly]

For reproducibility, can you provide an example of a minimal project that uses the Java SDK as a dependency and fails to build because of this issue? It would also be helpful to know what build tools you're using, and in what context you're seeing the message "java: package com.launchdarkly.sdk.server.interfaces does not exist".

[eli-darkly]

I ask because—

1. We're not really Java application developers; we build library code which by nature has to use a minimal feature set to remain compatible with an old LTS version, and so we don't necessarily have a clear picture of what a typical modern application build process would look like.

2. I'm not sure I understand what "Jigsaw is now mandatory" means in practice, since I haven't seen anything in the Java 17 release notes to indicate that packages without module metadata are no longer allowed. I'm wondering if this is more a case of "we have been accidentally including a module metadata file in there that we didn't intend to include, and it is wrong" in which case the best solution in the near term might be to fix the build so we don't have the file. And it will be easier to tell whether such a change is helpful if I have an example of a test project.

[eli-darkly]

There's something in the Shadow Jar task that is generating a module-info.class with improper data.

Well, I definitely see the incorrect module-info.class file. When decompiled, it looks like this:

module [email protected] {
  requires java.base;
  provides  java.nio.file.spi.FileSystemProvider with
    jdk.nio.zipfs.ZipFileSystemProvider;
}

I have no idea why a module descriptor for jdk.zipfs would be getting into our jars. However, I am seeing it in all of the jars: the default distribution, and "all", and "thin". I think that rules out the idea that the Shadow plugin is the cause, because we're not using Shadow for the "thin" jar.

Again, the most important piece of information for me right now is whether it is really "mandatory" for this library to have a module file when used in Java 17. If simply removing the bad module-info.class would be adequate, then that's what we need to do in the near term, because actually building the SDK as a module in the usual sense is not possible— we need to build in Java 8 for compatibility purposes, and module-info.java was not supported till Java 9.

[eli-darkly]

I think that rules out the idea that the Shadow plugin is the cause, because we're not using Shadow for the "thin" jar.

Sorry, correction - I am not seeing it in the "thin" jar, so it is still possible that Shadow is involved.

[eli-darkly]

@driverpt Could you please retest with the new 5.6.6 release? I fixed the Shadow problem that was causing that bad file to be included - so now there is no module-info.class in the jars. That is at least less wrong than before, but I don't know if it will resolve your build problem.

If it still doesn't work for you, then we'll need a little more information about your project and build tools (since it sounds like this is a build-time problem— we verified that the SDK code runs fine in Java 17), and/or a minimal example project to reproduce the problem.

[driverpt]

Hello @eli-darkly , totally forgot about this one. Mea Culpa!

It's working properly with Java 17!

Thanks