Research exporting public API packages as Java Module

[milleruntime]

It may be possible to use the Modules system, added in Java 9, to export the packages we want to treat as public API as a single module.

[keith-turner]

I read this and thought it was a good overview

http://tutorials.jenkov.com/java/modules.html

[milleruntime]

I think a good first step would be adding the Automatic-Module-Name to our JAR manifest files and getting our dependencies to set this property as well. Here is a good blog post explaining the situation:
http://branchandbound.net/blog/java/2017/12/automatic-module-name/

[keith-turner]

We should probably look for Accumulo dependencies that have not yet set Automatic-Module-Name and encourage them to set it.

[milleruntime]

We should probably look for Accumulo dependencies that have not yet set Automatic-Module-Name and encourage them to set it.

I am going to try and write a script to analyze our dependencies and generate a list. Otherwise it will be time consuming to inspect each JAR by hand.

[milleruntime]

It turns out the maven dependency plugin already does this so we can generate a list easily with the following command:
mvn dependency:list -DexcludeTransitive=true | grep "(auto)" | grep -v "optional" | sort | uniq

[milleruntime]

For dependencies that have not broached the subject yet, I created the following issues about adding automatic-module-name:

• https://issues.apache.org/jira/browse/CLI-299
• https://issues.apache.org/jira/browse/VFS-746
• https://issues.apache.org/jira/browse/CURATOR-550
• https://issues.apache.org/jira/browse/THRIFT-5023 (Fixed in THRIFT-5023 Add an Automatic-Module-Name entry thrift#2264)
• https://issues.apache.org/jira/browse/ZOOKEEPER-3625

[milleruntime]

Here is a list of dependencies without a module name and their status:

• com.beust:jcommander:jar:1.72:compile -- module jcommander (auto)
  Add Automatic-Module-Name cbeust/jcommander#385
• com.google.code.gson:gson:jar:2.8.5:compile -- module gson (auto)
  Include an automatic module name in the manifest google/gson#1238
• com.google.protobuf:protobuf-java:jar:3.7.1:compile -- module protobuf.java (auto)
  Fixed in 3.10.0: https://github.com/protocolbuffers/protobuf/releases/tag/v3.10.0
• commons-beanutils:commons-beanutils:jar:1.9.3:runtime -- module commons.beanutils (auto)
  Fixed in 2.0.0
• commons-cli:commons-cli:jar:1.4:compile -- module commons.cli (auto)
  Created https://issues.apache.org/jira/browse/CLI-299
• commons-logging:commons-logging:jar:1.2:compile -- module commons.logging (auto)
  https://issues.apache.org/jira/projects/LOGGING/issues/LOGGING-165
• com.sun.xml.bind:jaxb-core:jar:2.3.0.1:runtime -- module jaxb.core (auto)
  In Beta release 2.4.0-b180608.0325 - Split package between jaxb-impl and jaxb-core prevents usage as JPMS module javaee/jaxb-v2#1168
• javax.servlet:javax.servlet-api:jar:4.0.1:compile -- module javax.servlet.api (auto)
  Fixed in 4.0.3-RELEASE - https://github.com/eclipse-ee4j/servlet-api/blob/4.0.3-RELEASE/api/pom.xml#L193-L195
• jline:jline:jar:2.11:compile -- module jline (auto)
  Possibly in Jline3 Build as Java 9 modules jline/jline3#70
• junit:junit:jar:4.12:compile -- module junit (auto)
  Modules implemented in junit5
• log4j:log4j:jar:1.2.17:compile -- module log4j (auto)
  Fixed in 2.13.0
• org.apache.commons:commons-math3:jar:3.6.1:compile -- module commons.math3 (auto)
  https://issues.apache.org/jira/browse/MATH-1486
• org.apache.commons:commons-vfs2:jar:2.3:compile -- module commons.vfs2 (auto)
  Created https://issues.apache.org/jira/browse/VFS-746
• org.apache.curator:curator-framework:jar:2.12.0:test -- module curator.framework (auto)
  Created https://issues.apache.org/jira/browse/CURATOR-550
• org.apache.hadoop.*
  Open issue under support for Java 11: https://issues.apache.org/jira/browse/HADOOP-15786
• org.apache.thrift:libthrift:jar:0.12.0:compile -- module libthrift (auto)
  Created https://issues.apache.org/jira/browse/THRIFT-5023
• org.apache.zookeeper:zookeeper:jar:3.4.14:compile -- module zookeeper (auto)
  Created https://issues.apache.org/jira/browse/ZOOKEEPER-3625
• org.glassfish.jersey.*
  Define automatic module names eclipse-ee4j/jersey#4138
• org.slf4j:slf4j-api:jar:1.7.26:compile -- module slf4j.api (auto)
  Fixed in 1.7.28 - https://jira.qos.ch/browse/SLF4J-420

[milleruntime]

I am no longer planning on doing research for this so closing.

[EdColeman]

Isn't this something that will need to be done (eventually)? When that day comes, would any work done now be OBE,? Are there steps that should adopt now that would lessen future work / pain?

Why not keep it open as a marker for future technical debt? Maybe someone else would be interested?

[ctubbsii]

Isn't this something that will need to be done (eventually)?

Yes, probably.

When that day comes, would any work done now be OBE,? Are there steps that should adopt now that would lessen future work / pain?

The automatic module stuff above will be a useful starting point.

Why not keep it open as a marker for future technical debt? Maybe someone else would be interested?

It's not really technical debt, as modules aren't necessary or required. If somebody else is interested, we could always re-open or create a more narrowly scoped task. This one is a bit wide open, and there's no specific action to take in response to it. I'm not sure it's adding any value being perpetually open. If you want, you could add a "backlog" tag to it, or something to find it (and others like it) more easily later.

[ice1000]

JCommander has a substitute called picocli which supports jpms.