[foreign] NPE when trying to lookup a symbol in the default library when no libraries are loaded

[Jorn Vernee]

Hello,

I ran into an NPE while running some of the tests for foreign. This is 
the (much reduced) code to reproduce:

     Libraries.getDefaultLibrary().lookup("");

Throwing:

     Exception in thread "main" java.lang.NullPointerException
	at 
java.base/java.lang.ClassLoader$NativeLibrary.getFromClass(ClassLoader.java:2545)
	at java.base/java.lang.ClassLoader$NativeLibrary.findEntry(Native 
Method)
	at 
java.base/java.lang.ClassLoader$NativeLibrary.lookup(ClassLoader.java:2426)
	at com.github.jdnl.Main.main(Main.java:108)

If a NativeHeader annotation does not have a value for the `libraries` 
field, the default library is used for lookup (see 
LibrariesHelper::getSymbolLookupForClass), so that's how I discovered 
this error.

It seems that when you try to lookup a symbol in a library the findEntry 
function will call JNIEnv->FindClass which calls getFromClass 
(jni.cpp:403) to find the class loading the library:

ClassLoader.java:2544

     // Invoked in the VM to determine the context class in JNI_OnLoad
     // and JNI_OnUnload
     static Class<?> getFromClass() {
         return nativeLibraryContext.peek().fromClass;
     }

But if no native library is loaded (i.e. when using the default 
library), this context is empty, peek() returns null and you get an NPE. 
I have verified that the nativeLibraryContext is empty with debugging.

If I load a library (e.g. Libraries.loadLibrary(lookup(), "msvcrt")) 
before the call to lookup("") I get the expected result:

     Exception in thread "main" java.lang.NoSuchMethodException: Cannot 
find symbol  in library <default>
	at 
java.base/java.lang.ClassLoader$NativeLibrary.lookup(ClassLoader.java:2428)
	at com.github.jdnl.Main.main(Main.java:108)

I guess in the tests there is just always some native library that was 
already loaded, so nativeLibraryContext was never empty.

I'm not entirely sure what the default library is supposed to be. Is it 
just a dummy? Or is it backed by a bunch of system libraries? (in the 
former case a fix could be to override `lookup` in the `defaultLibrary` 
anonymous class to short-circuit the lookup process and throw a NSME 
early).

This didn't seem to be an issue caused just by running on windows, so 
I'm reporting.

Best regards,
Jorn Vernee