RFR JDK-8232624: Java cannot start: NewStringPlatform missing

Alexey Ivanov alexey.ivanov at oracle.com
Mon Oct 21 14:22:09 UTC 2019

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

I see no other way but to try both the decorated and
undecorated names like it was done for

> Thanks,
> David

More information about the hotspot-runtime-dev mailing list