RFR JDK-8232624: Java cannot start: NewStringPlatform missing
alexey.ivanov at oracle.com
Mon Oct 21 14:22:09 UTC 2019
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:
>>> 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
I see no other way but to try both the decorated and
undecorated names like it was done for
More information about the hotspot-runtime-dev