Comment by clumsysmurf
Comment by clumsysmurf 2 days ago
From what I have heard, Graal is still quite a headache if you are using libraries that are not compatible, but maybe this is out of date.
Comment by clumsysmurf 2 days ago
From what I have heard, Graal is still quite a headache if you are using libraries that are not compatible, but maybe this is out of date.
Only those reflection targets that are not "visible" from straight forward code. If you have code that accesses the "stringLiteral" field of a class, then it will be auto-registered for you. But if you access it based on user input, then you have to register it manually.
Also, quite a few libraries have metadata now denoting these extra reflection targets.
But nonetheless you are right in general, but depends on your use case.
Still an issue. The main problem is for native compilation you have to declare your reflection targets upfront. That can be a headache if your framework doesn't support it.
You can get a large portion of what graal native offers by using AppCDS and compressed object headers.
Here's the latest JEP for all that.
https://openjdk.org/jeps/483