JDK-8249215 : JFrame::setVisible crashed with -Dfile.encoding=UTF-8 on Japanese Windows.
- Type: Bug
- Component: client-libs
- Sub-Component: 2d
- Affected Version: 11,15,16
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: windows
- Submitted: 2020-07-11
- Updated: 2021-05-13
- Resolved: 2020-08-03
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 11 | JDK 13 | JDK 15 | JDK 16 |
|---|---|---|---|
| 11.0.10-oracleFixed | 13.0.6Fixed | 15.0.4Fixed | 16 b12Fixed  |
Related Reports
|
Duplicate :
|
|
|
Duplicate :
|
|
|
Duplicate :
|
|
|
Duplicate :
|
|
|
Duplicate :
|
|
|
Duplicate :
|
|
|
Relates :
|
Description
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.
Comments
|