<AWT Dev> [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

[Yasumasa Suenaga]

Hi Jay,

On 2020/07/23 19:09, Jayathirth D v wrote:
> Hi,
> 
> I tried reproducing the issue in my Windows 10 machine with UTF-8 encoding and test file mentioned in the bug, I don’t see any crash.
> Am I missing something?

OS locale may be affecting.

My laptop has been set Japanese (CP932 / Windows-31J), so WFontConfiguration attempt to find Japanese font by default.
However WFontConfiguration cannot find out the font of "DEFAULT_CHARSET" when -Dfile.encoding=UTF-8 is passed.


Thanks,

Yasumasa


> Also I think this should be in awt-dev so adding the mailing list.
> 
> Thanks,
> Jay
> 
>> On 20-Jul-2020, at 12:59 PM, Yasumasa Suenaga <suenaga at oss.nttdata.com> wrote:
>>
>> PING: could you review it?
>>
>>>    JBS: https://bugs.openjdk.java.net/browse/JDK-8249215
>>>    webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/
>>
>> Yasumasa
>>
>> On 2020/07/11 17:39, Yasumasa Suenaga wrote:
>>> Hi all,
>>> Please review this change:
>>>    JBS: https://bugs.openjdk.java.net/browse/JDK-8249215
>>>    webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/
>>> I tried to run Sample.java in JDK-8236161 with -Dfile.encoding=UTF-8, but JVM crashed due to internal error on fastdebug VM. I saw same call stack with JDK-8236161 in hs_err log.
>>> I investigated it, then I found out current implementation cannot handle default charset.
>>> If charset is set to UTF-8, it would be handled as "DEFAULT_CHARSET" in WFontConfiguration::initTables. However it does not affect native font name, so we cannot find valid font.
>>> This change has passed all tests on submit repo (mach5-one-ysuenaga-JDK-8249215-20200711-0655-12566039)
>>> Thanks,
>>> Yasumasa
>