JPMS support

[shs96c]

The JPMS has been part of the java platform since Java 9, and will be in an LTS release when Java 11 is released in September. Very slowly, projects are adopting the module system, but to do so the libraries that they depend on need to also support modules. It would be really helpful if okhttp had a module-info.class added somehow so we can make proper use of okhttp in a modularised build.

[shs96c]

The author of bytebuddy has created a maven plugin to generate this on a normal java 8 build: https://github.com/raphw/modulemaker-maven-plugin This links to: https://github.com/moditect/moditect which seems to be more fully-featured.

The selenium project has some magic called from their buck build that does something similar: SeleniumHQ/selenium@e57914a

It looks like okhttp uses maven, so the first option looks like a lower-stress way of adding this support without going having to move the entire build to Java 9+

[yschimke]

What is the feature you need here over just the defined names in the current jars? We set module names and even moved some packages around to have valid module jars already.

Just curious what isn’t possible currently.

[yschimke]

Reopen if there is something specific missing, over the current module support.

[Dragas]

JLink comes to mind. Automatic module usage prevents usage of jlink.

[yschimke]

Reopening temporarily for discussion, worth reviewing in the time since JDK 9.

What are other JDK libraries doing here? Is there established good practice.

[JakeWharton]

MR jars

[yschimke]

TIL: https://blog.gradle.org/mrjars

[JakeWharton]

Although maybe not the best introduction since Cedric is/was opposed to them. But yeah we can tuck a module descriptor into the jar without affecting Java 8 or Android so it seems like an obvious choice.

…

On Sat, Jun 20, 2020, at 1:51 AM, Yuri Schimke wrote: TIL: https://blog.gradle.org/mrjars — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4184 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQIENXDO3VYGEOL44UMLLRXRE4XANCNFSM4FM25XBA>.

[shs96c]

In Selenium we build for and target Java 8, but we add the module-info under META-INF/versions/9. This allows older tools that inspect bytecode in classes to continue to function as expected, since they don't know about the versioned directory, while allowing modern javas to use the module system properly.

I, too, am not a fan of using the MR jar approach to shadow classes, but for the case where the bytecode might be misinterpreted, I think that it's a reasonable solution.

[cowwoc]

@JakeWharton Can you please remove the needs info tag? Hopefully this will allow this feature request to move forward.

[cowwoc]

@yschimke A few months back I added multi-release JAR support to Hikari. It works great.

In Maven the change is as simple as https://github.com/apache/maven-compiler-plugin/blob/master/src/it/multirelease-patterns/singleproject-runtime/pom.xml#L102-L108. Hopefully Gradle makes it as easy.