JDK-8240521 : Revert backport of 8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: openjdk8u242,11.0.7
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-03-04
  • Updated: 2020-04-15
  • Resolved: 2020-03-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
openjdk8u252 b06Fixed
Related Reports
Relates :  
JDK-8235261 - Deadlock with ClassLoader.findLibrary and System.loadLibrary call
Relates :  
JDK-8231584 - Deadlock with ClassLoader.findLibrary and System.loadLibrary call
Description
The backport of the JDK-8231584 changes internal JDK fields processing. The problem is that the many third-party applications copy-pasted a hack that depends on particular JDK implementation 

First report: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-January/011026.html
Impact: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011303.html

The backport in current form may be inappropriate for older releases.
Comments
I'm interested to understand the use-cases where this hack is used. Is it because they didn't know about System.load or some other reason? When we encounter offending code like this, we should try to encourage its maintainers bring their use-cases to core-libs-dev for discussion.
23-03-2020
It's because they have old plugins that use native code, and some of them rely on this hack. TeamCity can't fix those plugins ��� for all I know there may not even be any source code! ��� so they have to provide an environment in which such plugins will continue to work. Of course TeamCity can change their own code, and they already have. It's a twentieth-century version of the "dusty deck problem". :-) The problem is that people will now use even more fragile ways to keep old code running. The advantage of keeping the "set sys_paths to null" hack working is that we can do that in a well--defined safe way, and that the cost of doing so is basically nothing.
22-03-2020
Libraries that ship with JNI libraries can just extract the shared library/DLL to a file system and use System.load to specify its absolute file. That API has been there since early JDK releases. The forum post from 2001 seems to be just the OP trying to use System.loadLibrary. Two of the replies report success when they switch to System.load. I'm interested to know why TeamCity can't use System.load, is there is an issue with dependences, rpath, or something else?
21-03-2020
Alan, this hack goes back to here: https://community.oracle.com/thread/1551225 So, almost 20 years. This hack is widespread and AFAIK there is no API which can work round the problem. Maybe we need to help out by keeping this working until we have a proper solution.
18-03-2020
> Thanks, hopefully they will fix their bug as its untenable to be hacking the JDK private fields like this They have marked that Teamcity issue as fixed and have released a newer version (from what I see in that issue tracker). However, I don't know what exactly the fix looks like (given that it's closed source). > They should bring their use-case to the core-libs-dev list for discussion. Not JetBrains, but someone else on the 8u-dev mailing list posted[1] an informative detail about the background behind this hack, which apparently isn't just limited to Teamcity. The crux of the matter appears to be this: <quote> 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. </quote> [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011303.html
18-03-2020
URL: https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/3272c495f495 User: dcherepanov Date: 2020-03-10 19:03:46 +0000
10-03-2020
Fix Request 8u There is no objections to revert the patch and make the hack work again at expense of exposing rare deadlock again Review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011313.html
06-03-2020
Suggesting to backout a patch jdk11u: JDK-8235261 jdk8u: JDK-8239160 Backout discussion: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-March/011307.html
04-03-2020
Thanks, hopefully they will fix their bug as its untenable to be hacking the JDK private fields like this. They should bring their use-case to the core-libs-dev list for discussion.
04-03-2020
Yes, @jpal provided a link https://youtrack.jetbrains.com/issue/TW-64232
04-03-2020
Is it TeamCity code that is hacking into the JDK internals? Is there an issue filed in their issue tracker for this?
04-03-2020