I don't even think there's even a wide view across the Java ecosystem
regarding JPMS. So far all usages of Apache Arrow I've seen do not require
JPMS, and amongst the sister projects I checked (Parquet, Iceberg), none of
them have added support for JPMS.
I don't know how many dependencies used by Arrow actually do not specify a
module name or provide module info, but if the way to address it is to get
all of them shaded within Arrow, then I would oppose this proposal as I
would imagine this would bloat all the jars and would make security issues
more complicated to discover and address (instead of quickly identifying a
vulnerable dependency through the dependency tree, it would require to also
check the shaded classes and get a new arrow version whereas it could have
been addressed by a simple dependency update)
On Thu, Jun 13, 2024 at 6:14 PM Norman Jordan
<norman.jor...@improving.com.invalid> wrote:
> 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.
>
