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 <suen...@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
