JDK-8035302 : Eliminate dependency on jdk.charsets from 2D font code.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-02-19
  • Updated: 2022-07-16
  • Resolved: 2015-04-14
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.
JDK 9
9 b65Fixed
Related Reports
Relates :  
JDK-8081741 - [Regression]Test closed/java/awt/font/LogicalFonts/MappingTest.java fails with UnsupportedCharsetException in Solaris Sparc
Relates :  
JDK-8081332 - AIX: fix charset dependenicies after 8035302:Eliminate dependency on jdk.charsets from 2D font code.
Relates :  
JDK-8073152 - Update Standard/ExtendedCharsets to work with module system
Relates :  
JDK-8080330 - (cs) Charset.availableCharsets failing with NPE on several platforms
Relates :  
JDK-8085948 - [Regression] Few Swing, AWT and 2D case fails with Decoder isn't implemented for WingDings Charset error on Windows
Relates :  
JDK-8282422 - JTable.print() failed with UnsupportedCharsetException on AIX ko_KR locale
Relates :  
JDK-8073893 - Enable charsets build system to configure euc_tw into java.base module/sun.nio.cs
Description
This bug concerns these dependencies:

sun.awt.FontDescriptor                   -> sun.nio.cs.HistoricallyNamedCharset (java.base)
sun.awt.HKSCS                            -> sun.nio.cs.ext.MS950_HKSCS_XP (sun.charsets)
sun.awt.motif.X11CNS11643$Decoder        -> sun.nio.cs.ext.EUC_TW (sun.charsets)
sun.awt.motif.X11CNS11643$Decoder        -> sun.nio.cs.ext.EUC_TW$Decoder (sun.charsets)
sun.awt.motif.X11CNS11643$Encoder        -> sun.nio.cs.ext.EUC_TW (sun.charsets)
sun.awt.motif.X11CNS11643$Encoder        -> sun.nio.cs.ext.EUC_TW$Encoder (sun.charsets)
sun.awt.motif.X11GB18030_0$Encoder       -> sun.nio.cs.ext.DoubleByteEncoder (sun.charsets)
sun.awt.motif.X11GB18030_1$Encoder       -> sun.nio.cs.ext.DoubleByteEncoder (sun.charsets)
sun.awt.motif.X11GB2312$Decoder          -> sun.nio.cs.CharsetMapping (java.base)
sun.awt.motif.X11GB2312$Decoder          -> sun.nio.cs.ext.DoubleByte (sun.charsets)
sun.awt.motif.X11GB2312$Decoder          -> sun.nio.cs.ext.DoubleByte$Decoder (sun.charsets)
sun.awt.motif.X11GB2312$Decoder          -> sun.nio.cs.ext.EUC_CN (sun.charsets)
sun.awt.motif.X11GB2312$Encoder          -> sun.nio.cs.ext.DoubleByte (sun.charsets)
sun.awt.motif.X11GB2312$Encoder          -> sun.nio.cs.ext.DoubleByte$Encoder (sun.charsets)
sun.awt.motif.X11GB2312$Encoder          -> sun.nio.cs.ext.EUC_CN (sun.charsets)
sun.awt.motif.X11GBK                     -> sun.nio.cs.ext.GBK (sun.charsets)
sun.awt.motif.X11GBK$Encoder             -> sun.nio.cs.CharsetMapping (java.base)
sun.awt.motif.X11GBK$Encoder             -> sun.nio.cs.ext.DoubleByte (sun.charsets)
sun.awt.motif.X11GBK$Encoder             -> sun.nio.cs.ext.DoubleByte$Encoder (sun.charsets)
sun.awt.motif.X11GBK$Encoder             -> sun.nio.cs.ext.GBK (sun.charsets)
sun.awt.motif.X11JIS0201                 -> sun.nio.cs.SingleByte (java.base)
sun.awt.motif.X11JIS0201                 -> sun.nio.cs.SingleByte$Encoder (java.base)
sun.awt.motif.X11JIS0201                 -> sun.nio.cs.ext.JIS_X_0201 (sun.charsets)
sun.awt.motif.X11JIS0201$Encoder         -> sun.nio.cs.CharsetMapping (java.base)
sun.awt.motif.X11JIS0201$Encoder         -> sun.nio.cs.SingleByte (java.base)
sun.awt.motif.X11JIS0201$Encoder         -> sun.nio.cs.SingleByte$Encoder (java.base)
sun.awt.motif.X11JIS0201$Encoder         -> sun.nio.cs.Surrogate (java.base)
sun.awt.motif.X11JIS0201$Encoder         -> sun.nio.cs.Surrogate$Parser (java.base)
sun.awt.motif.X11JIS0208                 -> sun.nio.cs.ext.JIS_X_0208 (sun.charsets)
sun.awt.motif.X11JIS0212                 -> sun.nio.cs.ext.JIS_X_0212 (sun.charsets)
sun.awt.motif.X11Johab$Encoder           -> sun.nio.cs.ext.DoubleByteEncoder (sun.charsets)
sun.awt.motif.X11KSC5601$Decoder         -> sun.nio.cs.CharsetMapping (java.base)
sun.awt.motif.X11KSC5601$Decoder         -> sun.nio.cs.ext.DoubleByte (sun.charsets)
sun.awt.motif.X11KSC5601$Decoder         -> sun.nio.cs.ext.DoubleByte$Decoder (sun.charsets)
sun.awt.motif.X11KSC5601$Decoder         -> sun.nio.cs.ext.EUC_KR (sun.charsets)
sun.awt.motif.X11KSC5601$Encoder         -> sun.nio.cs.ext.DoubleByte (sun.charsets)
sun.awt.motif.X11KSC5601$Encoder         -> sun.nio.cs.ext.DoubleByte$Encoder (sun.charsets)
sun.awt.motif.X11KSC5601$Encoder         -> sun.nio.cs.ext.EUC_KR (sun.charsets)
sun.awt.motif.X11SunUnicode_0$Encoder    -> sun.nio.cs.ext.DoubleByteEncoder (sun.charsets)

In our JDK modularization effort then AWT is in a desktop module and it is highly undesirable to have it reaching into the internals of the charset implementation to access specific charsets.
Comments
URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b6cce12949f3 User: lana Date: 2015-05-20 16:35:40 +0000
20-05-2015
URL: http://hg.openjdk.java.net/jdk9/jdk9/rev/0c68b8f51fe7 User: lana Date: 2015-05-20 16:35:09 +0000
20-05-2015
URL: http://hg.openjdk.java.net/jdk9/client/rev/0c68b8f51fe7 User: prr Date: 2015-04-14 00:06:27 +0000
14-04-2015
URL: http://hg.openjdk.java.net/jdk9/client/jdk/rev/b6cce12949f3 User: prr Date: 2015-04-14 00:06:24 +0000
14-04-2015
Mail from Phil suggests that we didn't make it clear that the highest priority issue that we want addressed here is the direct dependency on classes in the jdk.charsets module (sun.nio.cs.ext package). In particular we have to avoid a standard module (java.desktop) depending on a non-standard module (jdk.charsets). It would be be great if we can also eliminate the need for java.base to export sun.nio.cs to java.desktop but this is not high priority, and java.base is already exported a lot of other sun.* packages to java.desktop.
24-02-2015
Phil has started a review threads on this issue here: http://mail.openjdk.java.net/pipermail/2d-dev/2015-February/005093.html
24-02-2015
Even in the absence of the motif toolkit there have been times we need to use X11 to retrieve fonts and thus needed to be able to map from unicode to the X11 encoding. solaris/classes/sun/font/NativeFont.java explains how these fonts were used :- /* * Ideally there would be no native fonts used, and this class would be * unneeded and removed. Presently it is still needed until such time * as font configuration files (or the implementation equivalent) can have * all references to fonts that are not handled via Java 2D removed. * Currently there are two cases where this class is needed, both on * Unix, primarily Solaris, but useful on Linux too if fonts have moved. * 1. Some legacy F3 fonts are still referenced so that AWT "X/Motif" * can get dingbats and symbols from them. This can be dispensed with when * either AWT is based on 2D, or when the X font path is known to always * contain a Type1 or TrueType font that can be used in font configuration * files to replace the F3 fonts. * 2. When location of font files by 2D fails, because of some system * configuration problem, it is desirable to have a fall back to some * functionality that lessens the immediate impact on users. Being able * to perform limited operations by using bitmaps from X11 helps here. */ In addition Postscript printing makes use of encoding to embed strings in the postscript document in encodings understood by postscript printers. So removing these removes those capabilities, but fortunately the X11 usage is, or should be very rare these days. We had a remaining (not called out above) issue with Solaris CJK TrueType fonts having the important CJK bitmaps in external PCF format. I should see if those fonts still exist or have been replaced/removed on Solaris 11. The postscript code will need enhancing to use embedded fonts as I see no other answer. One way or another there's quite a lot of code upheaval that will result.
08-08-2014
All this dependencies are in the code related to fonts. I guess the best way to fix it is to move these classes(sun.nio.cs.ext) to java.nio.charset.
05-08-2014
This issue results in a module exporting Java SE APIs to be dependent on a JDK-specific module and therefore is important to fix.
09-05-2014