I see these possible solutions:
1.
No JPMS module information provided in Arrow Jar files
2.
Legacy Jar files are on the classpath, go in the UNNAMED module. Building and
running require extra flags "--add-reads" to give Arrow modules access to the
UNNAMED module.
3.
Legacy Jar files are treated as automatic JPMS modules and we accept the
limitation on the filename.
4.
Shade legacy Jar files into Arrow modules
Am I missing any other options?
________________________________
From: Laurent Goujon <laur...@dremio.com.INVALID>
Sent: Thursday, June 13, 2024 9:51 AM
To: norman.jor...@improving.com.invalid <norman.jor...@improving.com.invalid>
Cc: dev@arrow.apache.org <dev@arrow.apache.org>
Subject: Re: [DISCUSS][Java] Automatic Modules with JPMS
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.
>
