Support Java Modules

[aalmiray]

ion-java 1.5.1 defines an automatic module name

$ jarviz module descriptor --file ion-java-1.5.1.jar 
name: software.amazon.ion
version: 1.5.1
open: false
automatic: true
main-class: software.amazon.ion.impl._Private_CommandLine
requires:
  java.base mandated
contains:
  software.amazon.ion
  software.amazon.ion.apps
  software.amazon.ion.facet
  software.amazon.ion.impl
  software.amazon.ion.impl.bin
  software.amazon.ion.impl.lite
  software.amazon.ion.system
  software.amazon.ion.util

I'd be great if the library supplied a full Java module descriptor. It's possible to keep bytecode baseline compatible with Java 5 while providing a full module descriptor thanks to ModiTect. This will help modular projects that consume ion-java, specifically those that create custom Java Runtimes with jlink, as the latter does not support automatic modules but explicit modules. If interested I can send a PR to make it happen.

[popematt]

Thanks for bringing this to our attention. We'll need to understand the ramifications before we make any changes—I'll be the first to admit that I am only familiar with Java modules in a very general sense—but we would welcome a pull request.

Can you tell us anything more about ModiTect? I took a look at it, and it doesn't look like it is actively maintained. (For posterity, ModiTect also has a Gradle plugin, though it also looks like it's no longer maintained.)

Given that we only need one module-info.java for our project and that we intentionally don't have dependencies outside the Java std library, is there any reason we can't hand-write the module-info.java file once and forget about it?

Do you absolutely need ion-java 1.5.1? That version is nearly 4 years old, and there have been a significant number of bug fixes and performance improvements since then. We would prefer not to revisit such an old version if possible.

[aalmiray]

I'm currently consuming ion-java as a transitive dependency of com.amazonaws:aws-java-sdk-s3:$1.12.374 which is also not fully modular compatible. However, v2 of that API is (such as software.amazon.awssdk:s3:2.20.5).

The reason why I've stayed in v1 is because last time I checked v2 brings a boatload of dependencies due to reactive and async support, which I don;t need at all and would like to keep my dependency set as small as possible. This being said, perhaps I can have another look at v2 and see how/if the dependency graph may be trimmed down to a manageable size. If that were to be the case then I wouldn't need updates for ion-java in it's v1 form.

ModiTect is still maintained albeit not as fast as it used to be in the past. The Maven plugin lives at the core of the project while the Gradle one is provided as an external project. The current releases are stable enough even though their version numbers indicate RC. For example, the Jetty project relied on ModiTect to create module-info.class on the fly for their v9 and v10 releases IIRC. they switched to full modules and Java11 as baseline in v11, no longer needing ModiTect after that.

You could certainly hand-write module-info.java and make it part of the same compilation session, without having to rely on yet another external plugin like ModiTect.

[popematt]

I'm currently cinsuming ion-java as a transitive dependency of com.amazonaws:aws-java-sdk-s3:$1.12.374

So are you actually using Ion in your application, or are you only dealing with this issue because it's part of the AWS SDK?

[aalmiray]

Only because it's a part of the AWS SDK I require to post binaries to S3 buckets.

[aalmiray]

unfortunately v2 of the AWS SDK is not yet fully modular

$ jarviz module descriptor --gav software.amazon.awssdk:s3:2.20.5
name: software.amazon.awssdk.services.s3
version: 2.20.5
open: false
automatic: true
requires:
  java.base mandated
contains:
  software.amazon.awssdk.services.s3
  software.amazon.awssdk.services.s3.checksums
  software.amazon.awssdk.services.s3.endpoints
  software.amazon.awssdk.services.s3.endpoints.internal
  software.amazon.awssdk.services.s3.internal
  software.amazon.awssdk.services.s3.internal.crt
  software.amazon.awssdk.services.s3.internal.endpoints
  software.amazon.awssdk.services.s3.internal.handlers
  software.amazon.awssdk.services.s3.internal.resource
  software.amazon.awssdk.services.s3.internal.settingproviders
  software.amazon.awssdk.services.s3.internal.signing
  software.amazon.awssdk.services.s3.model
  software.amazon.awssdk.services.s3.model.selectobjectcontenteventstream
  software.amazon.awssdk.services.s3.paginators
  software.amazon.awssdk.services.s3.presigner
  software.amazon.awssdk.services.s3.presigner.model
  software.amazon.awssdk.services.s3.transform
  software.amazon.awssdk.services.s3.waiters
  software.amazon.awssdk.services.s3.waiters.internal

[popematt]

The last time I spoke with the people responsible for the AWS Java SDK, they told me that Ion is not actually supported by the SDK. Since it's apparently not needed by the AWS SDK and you're not actually using ion-java for anything, you should be able to exclude it from your dependencies. (Here's how, using maven or gradle.)

[aalmiray]

Thanks. I wonder if its inclusion as a dependency is remnant of a previous version of the SDK and someone forgot to take it out.