It's not clear to me why ISO2022_CN_CNS.newDecoder() is returning null, but we
should resolve this in Mantis. -- ###@###.### 2002/8/27
ISO2022_CN_CNS and ISO_2022_CN_GB provide encoder implementations only. In some respects this is not different to the situation for 1.3.1 and earlier.
See BugID 4140796. It turns out that historically the reason why these
named encodings don't provide ByteToChar converters is that the
ISO2022_CN Byte->Char converter will decode a stream containing both
escape sequences (CN_CNS and CN_GB).
The NIO implementation should probably throw an UnsupportedOperationException
for the moment but going forward an invokation of newDecoder() should
probably instantiate a ISO2022_CN decoder instance and pass back a reference
to it. In 1.4.1 no NIO ISO2022_CN decoder was provided. This should be added
for 1.4.2 as part of the cleanup of the handling of the NIO ISO2022 coders.
Rather than provide an incomplete ISO-2022-CN NIO Charset solution it is
proposed that the existing neutered encoder only implementations for
ISO-2022-CN-CNS and ISO-2022-CN-GB be removed from the NIO charset
provider class, sun.nio.cs.ext.ExtendedCharsets. A full ISO-2022-CN-*
implementation will be tracked into J2SE 1.5.