You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 26, 2020. It is now read-only.
It would be nice if there was a mechanism for having the Djinni support library load certain more critical classes before others. Specifically, the use case I have in mind is custom error handling classes used in custom implementations of jniSetPendingFromCurrent. If those are loaded later and you have any issues loading a class before them (eg you have a record that can be extended in Java and you accidentally use the wrong constructor signature), it'll throw a C++ exception, and your jniSetPendingFromCurrent will try to use the classes that aren't loaded yet, which will likely segfault. This type of failure is hard to debug and could be fixed in the common cases by loading the error handling classes first (unless those can't be loaded, but that's presumably less frequent).
The text was updated successfully, but these errors were encountered:
Interesting idea. The actual loading of the class in Java is is something you could accomplish on your own if you write a custom JNI_OnLoad, or could handle from Java externally. Getting the static class-info helpers populated would require some changes to the JNI support library.
It would be nice if there was a mechanism for having the Djinni support library load certain more critical classes before others. Specifically, the use case I have in mind is custom error handling classes used in custom implementations of
jniSetPendingFromCurrent
. If those are loaded later and you have any issues loading a class before them (eg you have a record that can be extended in Java and you accidentally use the wrong constructor signature), it'll throw a C++ exception, and yourjniSetPendingFromCurrent
will try to use the classes that aren't loaded yet, which will likely segfault. This type of failure is hard to debug and could be fixed in the common cases by loading the error handling classes first (unless those can't be loaded, but that's presumably less frequent).The text was updated successfully, but these errors were encountered: