In JDK 1.1.x and Java2, character converter's classes
are not public.
These are in sun.io package, not official APIs.
Character Encoding Converter APIs are required.

We want to use the converters directly.
And I heard the converters will be fast, smaller, 
more efficient in next upgrade release of Java2.
I think the APIs will be fixed at that release.
So I think there is no problem 
for the converters to be public official APIs.

I want to use followin APIs.
   o for substitution strategy
         sun.io.CharToByteConverter#setSubstitutionMode(boolean) 
         sun.io.CharToByteConverter#setSubstitutionBytes(byte[]) 
         sun.io.ByteToCharConverter#setSubstitutionMode(boolean) 
         sun.io.ByteToCharConverter#setSubstitutionChars(char[]) 
   o for caching of converters and direct use of converters
         String#(byte[],int,int,sun.io.ByteToCharConverter) 
         String#getBytes(sun.io.CharToByteConverter) 

Of course I want to use all useful public method of converters,
but above methods are indispensable.
For example, the program which converts any HTML page
within wrong encoded characters to Strings
must handle the error during converting.

If converters are public APIs,
BugID 4041096, 4022676, 4201069, 4154030, and 4155601
would be solved, too.

Because our application want to use above method,
it cannot be 100 percent Pure Java application.
(100 percent Pure Java applications must not
 use sun.xxx classes directly.)
This is show-stopper for us.

We recommend Converter API will be public Core API
in the next upgrade release(Kestrel) of Java2.

The only thing you have to do is
to make sun.io.CharacterEncoding,
sun.io,ByteToCharConverter, sun.io.CharToByteConverter,
and a few classes public classes(java.io.xxx),
and to make above String constracters and methods public.
(I understand above changes will require
a a great deal of labor....)
(Review ID: 56690)
======================================================================




java version "1.2.2"
Classic VM (build JDK-1.2.2-W, native threads, nojit)


I need to convert a string to the platform's default character encoding.
This is exactly what String.getBytes() does.
However, I want to know when it fails, i.e. when it is not possible
to represent the unicode chars in the String in the character encoding.
It is totally unacceptable in this application to simply substitute a question
mark.
Doing this operation should be easy -- the String conversion code is based on
sun.io.CharToByteConverter which has the method setSubstitutionMode, and throws
UnknownCharacterException.
Since we aren't supposed to directly invoke sun.io classes, please
expose this in the String methods.
In  xxxxx  words, add setSubstitutionMode to String, and a variant of
getBytes which throws the UnknownCharacterException.

Alternatively:
Document the sun.io.CharToByteConverter class and explicitly permit it
to be called on any java platform.
(Review ID: 99665)
======================================================================

no workaround.
Or to make another whole character converters for oneself...
======================================================================

This will be addressed under RFE 4287465, but I'm leaving this one open because it has additional information.
 xxxxx@xxxxx  2000-02-25

Fwiw, Bug 4239372 is a related but different 
request. There I was asking for a way to create 
new encodings by registering encoding names and 
classes (or, presumably, factories) with some
standard class.

there is a workaround, but inefficient ...
test new String( s.getBytes( enc), enc).equals( s)
to see if conversion was successful and reversible.
Also see
http://www.gjt.org/javadoc/org/gjt/cuspy/ByteString.html
which has conversion methods that throw exceptions instead
of substituting.  (Currently, those methods are implemented
using the exact workaround shown here, but they make it
transparent.  If a later API exposes the substitution mode,
the methods of ByteString can be made more efficient, but
programs that use ByteString won't have to be changed.