Open danepitkin opened 1 year ago
Not until Java 21+ (or really Java 24, when the new memory APIs will presumably be stabilized)
Also, this is a runtime flag, not a build flag
Ah I see. Updated to reference runtime now. Shall I close this given this won't happen any time soon?
The interesting things to me would be (1) implementing an arrow-memory-ffm that uses the experimental API so we can figure out how well it works and (2) refactoring BufferAllocator and other core APIs to be in line with the new upstream APIs so that when Java 24 comes, we're ready
Because if something is missing for us it's kinda too late to communicate any feedback upstream
Describe the enhancement requested
Add a memory module that uses the java.lang.foreign module (currently in preview, APIs updated in Java 21).
When using Java 9 or later with the current implementations, some JDK internals must be exposed by adding --add-opens=java.base/java.nio=ALL-UNNAMED to the java command[1]. Here's an article that explains the general Java issue here[2].
Can using java.lang.foreign remove this dependency so users do not have to run with custom options ?
[1]https://arrow.apache.org/docs/java/install.html#java-compatibility [2]https://community.snowflake.com/s/article/JDBC-Driver-Compatibility-Issue-With-JDK-16-and-Later
Component(s)
Java