[PATCH] Windows 32-bit DLL name decoration

Alexey Ivanov alexey.ivanov at oracle.com
Wed Dec 12 15:34:18 UTC 2018

On 12/12/2018 12:58, Magnus Ihse Bursie wrote:
> On 2018-12-12 12:35, Alan Bateman wrote:
>> On 12/12/2018 11:14, Magnus Ihse Bursie wrote:
>>> :
>>> I searched the code for "jdwpTransport_On" to see of there was any 
>>> corresponding OnUnload function (or other), but could not find any.
>> That's right, an unload wasn't needed when that SPI was originally 
>> added but could be added in the event that some future debugger agent 
>> need it. The SPI is a supported/documented JDK-specific mechanism, 
>> its "spec" is hosted here:
>> https://docs.oracle.com/en/java/javase/11/docs/specs/jdwp/jdwp-transport.html 
> ... yet in all that time, we have not fully supported the spec on 
> Windows 32. :-( (We never discovered this because of lack of testing, 
> I presume, and that our internal usage empoyed a questonable workaround.)

The spec does not specify whether the mangled name should be exported or 
not (for Windows 32 bit).

I looked through JNI specification and have found no mention of 

This example uses extern "C" modifier but neither JNIEXPORT or JNICALL:

>> I see this thread is touching on the functions exported by libjli. 
>> This library is part of the launcher and shouldn't be used directly 
>> by anything outside of the JDK. However we have to be careful because 
>> JavaFX `javapackager` tool has been using it. There's a JEP to bring 
>> a similar tool, jpackage in the current proposal, that will supersede 
>> it but in the mean time we need to be careful not to break it. A 
>> second issue is that the libjli is listed in the property list 
>> (Info.plist) on macOS. This came from Apple in 7u4 and periodically 
>> things show up that are using it, e.g. that recent breakage with 
>> Eclipse that was never fully diagnosed but we think it was using 
>> Info.plist.
> The latest patch, as suggested, will not modify JLI, but instead fix 
> the broken behaviour of JDWP on Windows 32.

Yes, that's right.
However, I believe the previous versions did not modify libjli.


> /Magnus

More information about the core-libs-dev mailing list