We will also need to modularize the libraries we package, including but not limited to:

• All the JNR libraries
• bytelist/jcoding/joni
• utility and JVM shim libraries (invokebinder already done)

We also package several third-party libs and will want to see if they've started modularizing.

Tentatively marked for 9.2.

One big wrinkle here is that if we start including module-info in a project, we're going to need Java 9 tooling to build it. That's not a huge leap for some of the libraries, since we control them and are generally the only ones maintaining them, but JRuby itself is built by and for many different systems, some of which may not have Java 9 for a while.

@headius Maybe just a separate build target for a modularized Java 9 deployment that includes the module-info, akin to how there are currently binary, Windows executable, source and complete jar packages of the jRuby release.

I'm trying to wrap up my day, but perhaps @raelik or someone else observing this issue can research whether there are any ways to build module-info.java without a Java 9 install present. I know we can make this produce a jar that works on Java 7 or 8, as I did in https://github.com/headius/invokedynamic.

@headius as far as I can see, the syntax of the module-info.java file is only understood by Java 9's javac.

@raelik Yeah, I'm just wondering if there's a way to pull down OpenJDK 9's javac or an equivalent javac that understand module-info.java without running on 9.

We will put more focus into module support over the summer in preparation for the Java 11 LTS release.

Some of our deps have been modularized: jcodings, joni. The bytelist library has been rolled back into JRuby proper due to duplicated packages.

The jnr projects still need to be modularized.

I added an automatic module name in 681ab22.

More to come, ideally with full proper modularization in 9.2.2.

#6596 removes BSF entirely to dodge that whole issue.

jzlib appears to no longer be maintained. I am trying to ascertain its status, but we may be forced to take over the library (perhaps with the help of others) in order to modularize it.

ymnk/jzlib#25

I believe for libraries that do not have module support, we could just continue shading them... but ideally we would have proper modules up and down the JRuby dependency stack.

Missed dependency: com.martiansoftware:nailgun-server

I would propose that we finally remove the rest of Nailgun support in 9.3.

Nailgun support was partially removed in #5981 and the rest is removed in #6597.

joda-time has module support and we are on the latest.

org.apache.ant:ant and org.osgi:org.osgi.core are not shipped with JRuby and may not need modularity. Unsure how sources in JRuby that optionally depend on osgi will work in a module environment.

Why JRuby cannot just use java.util.zip.Deflater/java.util.zip/Inflater instead of JZLib?

@slonopotamus I don't recall the exact features, but there are some low-level aspects of zlib exposed by the Ruby library that we could not get from the built-in deflater and inflater. It is possible those features have been exposed in the decade since we switched to jzlib, but I have not done that audit.

If we can eliminate jzlib that would be a positive... not because there's anything wrong with it as a library but because it would be one less dependency.

@slonopotamus I was curious so I dug back to this commit, which was the first move to JZlib: 908cd08

The commits this squashed explain some of the behaviors we could not get out of the default JDK library, such as:

• Various specific error conditions hidden behind java.util.zip's generic exceptions
• Methods that could not be supported: GzipReader#unused, GzipWriter#sync, GzipWriter#sync=, GzipWriter#flush

It would be great if we could do everything with java.util.zip (if possible) but it is not a priority for us right now. We would happily support anyone that wanted to attempt it!

Linking to #6598 which has been punted to 9.4. The issues are listed there, but most of the to-do's in this issue are resolved. Nearly all libraries have at least an automatic module name, and we will try to get full descriptors into them for 9.4. Unfortunately JDK-8263432 prevents us from doing this modularization move in 9.3.

This one needs to keep getting kicked down the road. We have made great improvements to module support in 9.3 and 9.4, but we still cannot build cleanly with modules active and we have several libraries that attempt to cross module boundaries illegally.

Punting to 9.4.1, because we really need to fix this before 9.5.

Remaining work needs to happen in 9.5 but we are functioning well under all JPMS versions of JDK currently.