normanj-bitquill commented on issue #38051: URL: https://github.com/apache/arrow/issues/38051#issuecomment-2159402523
I've looked into this and have some notes. ### Java Modules ### When compiling Java code in Java 9 or higher, you can use both the classpath and the module-path. * All libraries in the classpath are considered to be part of the `UNNAMED` module. * All libraries in the module path that contain a `module-info.java` file will be a Java module as expected. * All libraries in the module path the do not contain a `module-info.java` file will be treated as automatic Java modules. The names of the modules are dependent on the name of the Jar file. This creates deployment issues. ### Maven with Java Modules ### Maven may choose to use both the classpath and module-path. * If the Java target is 9 or greater and the current Maven module contains a `module-info.java` file, then all libraries with a `module-info.java` file will be placed in the module-path. All other libraries will be on the classpath (this can be configured). * Maven can be told to also place libraries without a `module-info.java` file in the module-path. This will cause them to become automatic Java modules. ### Getting Started ### A first step migrating to Java 11 would be to remove (or hide) the `module-info.java` files. This would cause Maven to put everything on the classpath and not cause any build issues. We would not be distributing any module information, so consumers would have to treat Arrow modules as either automatic Java modules or put them on the classpath. Without the `module-info.java` files, IntelliJ can easily resolve dependencies and is able to run unit tests. ### Longer Term ### Longer term, we should include proper `module-info.java` files in all Arrow modules. Not all of Arrow's dependencies have a `module-info.java` file, such as `flatbuffers-java`. It is not reliable to treat these as automatic Java modules during build, since that depends on the file name. We could either shade in the java classes or keep such dependencies on the classpath. If they are on the classpath, then we cannot declare any dependency on them in the `module-info.java` file and consumers may need extra flags when compiling/running projects depending on Arrow. I recommend shading in legacy dependencies. This ease the burden for consumers of Arrow libraries. We would not expose packages from those libaries. Consumers can simply add Arrow libraries to the module path without needed flags to grant Arrow modules access to the UNNAMED module. Some dependencies are obsolete, such as `jsr305`. We should migrate away from obsolete dependencies. The `ThreadSafe` annotation could have use, but it is becoming increasingly unlikely that anyone would consume it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
