For clarity, this only applies to legacy libraries that Arrow depends on. All
Arrow modules are proper JPMS modules and have a "module-info.java" file.
________________________________
From: Norman Jordan <norman.jor...@improving.com.INVALID>
Sent: Thursday, June 13, 2024 9:08 AM
To: dev@arrow.apache.org <dev@arrow.apache.org>
Subject: [DISCUSS][Java] Automatic Modules with JPMS
Do we want to continue to use automatic modules with JPMS? Is there a wider
Apache view on automatic JPMS modules?
An automatic module is a Java library that does not have a "module-info.java"
file and is included in the "source-path" for Java 9 or higher. Java will
create a module with a name based on the filename of the Jar file.
Advantages:
*
Makes it easy to have JPMS dependencies on legacy libraries
*
Allows the use of legacy libraries without putting them in the UNNAMED module
and requiring flags at build/run time
Disadvantages:
*
Adds a limitation on the Jar filenames of legacy libraries
*
At build time there is a clear warning displayed mentioning that it is unsafe
to distribute a project using automatic modules
To better understand the issue, let's consider a legacy library
(flatbuffers-java). A user of Arrow would be expected to have the Arrow Jar
files as well as the dependencies. If they use the name "flatbuffersjava.jar"
for the "flatbufffers-java" Jar file, then Java will create a different "JPMS"
module ("flatbuffersjava" in this case) and all declared dependencies on
"flatbuffers.java" would fail.
This is an unlikely scenario especially since most people would build using
Maven or Gradle. It is adding another restriction on how users build projects
with Arrow though and may be difficult to communicate.
A possible workaround is to shade in legacy Jar files. The classes from them
would be included in Arrow Jar files. A user of Arrow would no longer see a
dependency on legacy libraries and would not need to worry about Java flags or
filenames.
