[
https://issues.apache.org/jira/browse/DERBY-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17305010#comment-17305010
]
Romain Manni-Bucau commented on DERBY-7108:
-------------------------------------------
Hi [~rhillegas], found a small blocker - not sure it is my single issue:
org.apache.derby.impl.sql.GenericStatement#prepMinion. it ends up to generate
some bytecode and load it in a classloader (in graal there is no dynamic
classloader, just the static one of the build). We can solve it by generating
these classes at build time if possible or it would be neat to replace the
bytecode generation by some runtime implementation if possible.
> Make derby graalvm friendly
> ---------------------------
>
> Key: DERBY-7108
> URL: https://issues.apache.org/jira/browse/DERBY-7108
> Project: Derby
> Issue Type: Task
> Affects Versions: 10.16.0.0
> Reporter: Romain Manni-Bucau
> Priority: Major
> Attachments: outs.zip
>
>
> Hi,
> It would be neat to be able to use derby embedded with graalvm.
> Some work started at [https://github.com/apache/geronimo-arthur/tree/openjpa]
> (see [https://www.mail-archive.com/[email protected]/msg97748.html)]
> but I faced some weird issue about derby context.
> Wonder how derby community considers graalvm (h2 for example explicitly said
> it will never care about it and is happy with having broken graal support in
> a minor version which is their choice but also means there is no point
> integrating it since work can be to redo for each minor).
> If you are interested I'm happy to collaborate if needed to try to make it
> supported through arthur or native native-image configuration (can sit in the
> derby jar to work OOTB too).
> Side note: if it helps we can chat on asf slack.
> Romain
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
