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
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


More information about the core-libs-dev mailing list