ClassLoader.loadLibrary NullPointerException Regression in 8u242

[Severin Gehwolf]

Hi,

On Wed, 2020-03-04 at 10:23 +0100, Laurent Goubet wrote:
> Hello,
> 
> Sorry, this is supposed to be an answer to the following thread but I 
> don't know if it is possible for me to answer a thread that existed 
> before I joined the mailing list : 
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-January/011057.html
> 
> I am also reproducing this issue when running my product on an OpenJDK 
> and I wanted to give you a background on why the ClassLoader.sys_paths 
> can be set to "null" through reflection.
> 
> The very root cause of this is due to implementers that need to update 
> the java library path at runtime for one reason or another. Oracle JDK 
> does not support this because of a cache in the ClassLoader (usr_paths) 
> that is initialized to the value of "java.library.path" when the VM 
> runs, and never updated _unless_ sys_paths is null. So if I want to use 
> "System.setProperty("java.library.path", 
> System.getProperty("java.library.path") + File.pathSeparator 
> +"my/library/path")" and then use System.loadLibrary(...) to get a 
> library in that new path I've added, my only way is to reset 
> ClassLoader.sys_paths to null.
> 
> This is actually a workaround that had been initially shared by a Sun 
> engineer (apparently) at 
> http://forums.sun.com/thread.jspa?threadID=707176 ... The forum no 
> longer exists at that url and I haven't found a cache anywhere, but 
> simply searching for that url on google will return a few results of 
> people copy/pasting the comment about the source of the workaround... I 
> guess there are a lot more programs using that workaround without citing 
> the source.
> 
> This is an implementation detail, but it seems to be used by quite a few 
> people to force the JDK to reset its library path, so it would be nice 
> for OpenJDK to support that as well instead of failing in NPE.

We are aware of the issue and having user code out there which changes
internal fields is *very* unfortunate to say the least.

JDK-8194653[1] was the bug which changed this for 8u242. If we can fix
JDK-8194653 without breaking this use case I'd be amenable to approve
such a fix. So far it's unclear whether that's possible.

Thanks,
Severin

[1] https://bugs.openjdk.java.net/browse/JDK-8194653