Backport: [GR-49816] Throw exception for null pointers passed to RuntimeJNIAccess / RuntimeReflection register methods #15
Conversation
Don't allow null values to be passed to the `register` method of `RuntimeJNIAccess` and `RuntimeReflection`. Since these are public APIs GraalVM should either handle null values (by ignoring them in this case) or throw a `NullPointerException` before creating an asynchronous task to perform the registration in the analysis, which then results in `NullPointerException`s being thrown later when it's no longer possible to understand where the null value originate from. (cherry picked from commit e6c12dd)
(cherry picked from commit d621dbd)
Not before the register methods, which can miss cases, nor later on in a runnable. (cherry picked from commit f94551a)
(cherry picked from commit d996f32)
(cherry picked from commit 0ba6cc2)
oracle-contributor-agreement
bot
added
the
OCA Verified
|
@zakkak PTAL. Thank you! |
There was a problem hiding this comment.
Thank you @jerboaa.
The only difference is in 6af144f where the original had some
importre-shuffeling and the rename frommethodstoexecutables, which isn't done in the backport.
I understand that the re-shuffling is not applicable (since the imports are not present in this repository) but why not backport the methods to executables renaming? Wouldn't that reduce the chances of future backport conflicts?
It probably would, but it also adds noise that isn't necessary for the fix. What's more that is what was done on the Mandrel 23.1 side as well so stuck with that. I don't think it's a big deal either way. Let me know what you feel is best and I'll do that. |
Almost a clean backport of: oracle/graal#6985 to bring upstream community repo more in sync with downstream Mandrel 23.1 release branch.
The only difference is in 6af144f where the original had some import re-shuffeling and the rename from
methodstoexecutables, which isn't done in the backport.Thoughts?