Transitioning from quarkus JVM to GraalVM #42973
Unanswered
UrCoderPal
asked this question in
Q&A
Replies: 1 comment 1 reply
-
For classes that are not under your control (coming from 3rd party libraries) I am afraid you can't do much. For classes under your control you can either refactor them to be native-image friendly or use helper functions that reference the super methods and fields to avoid the need of extensive
Do you mean that
|
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
used tips and solution from issue #34854 but now stuck with a problem:
I want to substitute the org.jose4j.keys.EdDsaKeyUtil class which extends the OctetKeyPairUtil and this the KeyPairUtil class which is of 'default' access.
So now when i have to override the abstract methods of KeyPairUtil in my TargetEdDsaKeyUtil class i am restricted. I thought of creating substitutes for all three but then in my TargetKeyPairUtil the @TargetClass(org.jose4j.keys.KeyPairUtil.class) also gives an error because the value we are passing here is inaccessible.
I intended to keep all the implementation logic intact.
Selectively substituting methods causing build issues is an option but in my case those methods are using default access methods of their superclass so then replicating each such method and fields(using @alias annotation) could later on cause me logical issues and may break the code eventually.
What do u guys suggest?
@gsmet @zakkak @geoand
Beta Was this translation helpful? Give feedback.
All reactions