Quarkus org.graalvm.nativeimage.svm IllegalArgumentException: Unsupported api 524288 ClassVisitor Gizmo #10498
Comments
|
The issue is that the GraalVM svm artifact includes a non-shaded version of ASM which conflicts with the official ASM dependency brought by Quarkus. This is very bad practice, I wonder why we never found out about this. /cc @galderz @dmlloyd If I remove this dependency and all your *Feature classes depending on it, tests pass. That being said, I think we should discuss what you're trying to do and which issues you are trying to solve with this setup as it might be something we would like to fix at a more general level. Thanks. |
|
*Feature classes are to solve a problem occurs in native mode. This problem and solution is explain in this topic : |
gastaldi
added
the
env/graalvm-java11
|
/cc @jaikiran you might be interested in this one too as I know you like to poke the GraalVM bear :). |
|
This one seems to have been fixed recently in upstream Graal in this PR oracle/graal#2543 as part of this issue oracle/graal#2528. I no longer see these ASM classes being copied into the svm.jar in latest upstream Graal master branch. Not sure if they have plans for a 20.1.1 release and whether they would be interested in including this one in that release. |
|
@jaikiran care to ask? Sometimes, they consider backporting things if we ask gently. |
|
Hello @galderz, I wasn't aware of Mandrel. Now that you mentioned it, I read up this doc https://github.com/graalvm/mandrel/blob/master/README-Mandrel.md. It does a good job explaining what it is and how it differs from Graal VM. The doc currently focuses on the runtime aspects of the differences. On the development/dependency point of view, does Mandrel use a different set of Maven co-ordinates (groupid:artifactid) for its artifacts or are they the same? The reason I ask that is, if this does indeed get resolved (only) in Mandrel, do users have to update their pom.xml to use a different Maven co-ordinate for the SVM artifact (and ban the Graal VM one?). |
|
@jaikiran The coordinates would be the same, only the version would change. However, we've not yet published Mandrel artifacts since we've not had the need to do so. I'll work with the other Mandrel engs to publish them. If the difference is only the version, for a Maven build they could override the version in their pom.xml, or pass in as command line argument: |
|
This is pretty old and likely not an issue anymore, so I'll close it. If it's still a problem, feel free to comment |
Describe the bug
I tried to bump quarkus version from 1.5.0.Final to 1.5.2.Final. I obtain the following error message :
(The concerned project : https://github.com/myriadata/MyriaInvoiceApi - branch develop)
It is happened when I tried to bump from 1.5.0.Final to 1.5.1.Final or 1.5.2.Final
Expected behavior
Project must build :)
Actual behavior
Project don't build.
I use @AutomaticFeature to bypass i18n locale problem when I run in native mode.
I have got some fix in fr.myriadata.myriainvoice.api.conf.graalvm to allow to have i18n and l10n in native mode too.
I know if I remove this @AutomaticFeature class, I don't have this unexpected behavior but i18n and l10n don't work.
To Reproduce
Steps to reproduce the behavior:
Environment (please complete the following information):
uname -aorver:java -version:I also tried :
mvn --version):Additional context
Thank you :)
The text was updated successfully, but these errors were encountered: