Hi David,
On 21/10/2019 14:00, David Holmes wrote:
On 21/10/2019 10:14 pm, Alexey Ivanov wrote:
Hi David,
On 21/10/2019 02:19, David Holmes wrote:
<SNIP>
So what would happen if we drop the JNICALL from JNU_NewStringPLatform?
Yes, it will be found by its undecorated name too.
But I'd rather not change the calling conventions of functions with
JNU_ prefix.
Yes you are right. All the JNU_ methods are declared as JNICALL and
they all work fine.
The issue/problem here is that we have the JVM using os::dll_lookup to
find a method back in libjava and that can't be a JNICALL else the
lookup won't work (without jumping through extra hoops).
So, I think the proposed patch is the easiest and safest way to fix
32-bit Windows build.
Yes I now agree. Thanks for bearing with me.
Another way to fix it is to lookup the undecorated name first and,
if it fails, to lookup the decorated name, which makes the code
harder to read.
With this patch, I'm reverting the code to the state it was before.
Yes, but Claes didn't like the way it was before :) so I'm hoping we
can keep his cleanup whilst still allowing Windows to work correctly.
Probably, Claes thought "NewStringPlatform" wasn't used. Yet it
proved that "NewStringPlatform" is still used.
If required, I can create a follow-up issue to re-do the cleanup as
Alan suggested.
Okay. Though I'm not sure what form that might take.
I have submitted
https://bugs.openjdk.java.net/browse/JDK-8232724
I see no other way but to try both the decorated and
undecorated names like it was done for
https://bugs.openjdk.java.net/browse/JDK-8214122
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057396.html
Thanks,
David
--
Regards,
Alexey
