Repository navigation
[Java] java.lang.reflect.InaccessibleObjectException on Java 18 #340
Description
Activity
David Li / @lidavidm:
CC @davisusanibarRaúl Cumplido / @raulcd:
Hi Daniel,Thanks for your report. We are working towards supporting newer JDK versions.
Support for JDK 17 will be added to the next 8.0.0 release as you can see from this ticket https://issues.apache.org/jira/browse/ARROW-15755 .
Support for JDK 18 is expected to be added to a following release. You can follow how support for JDK 18 progresses on this ticket: https://issues.apache.org/jira/browse/ARROW-16267
Daniel Glöckner:
Thanks @lidavidm and @raulcd. I will trace the Arrow release and re-test.Daniel Glöckner:
@lidavidm I re-tested with the Arrow 8.0 release and java 17.0.2.The minimal code below only works if I add
--add-opens java.base/java.nio=ALL-UNNAMEDVM option. Is this expected?import org.apache.arrow.memory.RootAllocator; public class Arrow { public static void main(String[] args) { RootAllocator rootAllocator = new RootAllocator(); var buf = rootAllocator.buffer(1024); System.out.println(buf); } }
David Li / @lidavidm:
[~gloeckner.daniel@googlemail.com] I believe this is currently unavoidable because of Arrow/Netty's use of direct memory, cc @davisusanibar for comments. (JEP419 may help but we are a very long way off from being able to rely on that.)David Dali Susanibar Arce / @davisusanibar:
Hi [~gloeckner.daniel@googlemail.com] as per the jar artifacts are exposed as a legacy mode (it means any jar are running in the classpath is consider as a unnamed module) and base on JEP 200 The Modular JDK: yes, this is needed:--add-opens ${module}/${package}=${target_modules}
Let the ${target_modules} access all types and members, regardless of visibility, from ${module}'s ${package}Also this is added to the Arrow Java documentation 8.0.0 at https://arrow.apache.org/docs/java/install.html
—
This is a draft for implement JEP 200 The Modular JDK and be more restrict about to not give ALL-UNNAMED access but there is a lot of discussion we need to close before to convert this draft into PR: apache/arrow#13072
David Dali Susanibar Arce / @davisusanibar:
Hi [~gloeckner.daniel@googlemail.com] please could you help us if we could close this issue as resolved ?, thank you in advance.Fabian Mastenbroek:
Hi,I stumbled upon this issue today and ideally I would like to avoid having to open
java.baseto unnamed modules. I took a look at the source code of MemoryUtil today and it seems there might be workaround for this issue.The reflective call that is currently causing the failure is not necessary. Applying this patch to the Arrow tree seems to resolve this issue for me. However, without the suggested add-opens parameter, any call to MemoryUtil.directBuffer will now fail during runtime.
This patch resolves that issue for me. However, this is a rather hairy solution, since it overwrites fields of DirectByteBuffer using Unsafe to construct a buffer for an arbitrary memory address.
David Li / @lidavidm:
CC @davisusanibar @lwhite1 for opinionsWe can't solve this without rewriting the memory subsystem (unfortunately). FFM is a better potential solution.
Getting the following stack trace when running on Java 18.
BaseAllocatorthrows this when it calls theDefaultAllocationManagerFactory.Reporter: Daniel Glöckner
Related issues:
Note: This issue was originally created as ARROW-16449. Please see the migration documentation for further details.