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
JNIEXPORT or JNICALL.
https://docs.oracle.com/en/java/javase/11/docs/specs/jni/index.html
This example uses extern "C" modifier but neither JNIEXPORT or JNICALL:
https://docs.oracle.com/en/java/javase/11/docs/specs/jni/design.html#native-method-arguments
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.
Regards,
Alexey
/Magnus
