This is the i18n related part of bug 4927428 which reports the following
general problem in the jdk.


We are currently into porting J2SE V1.4.2 to our mainframe platform,
where the native encoding is EBCDIC. Several tests in JCK failed because
of the careless use of java.lang.String.getBytes() in other java classes;
use of native encoding is essentially wrongfully hardcoded into these
classes.

We compiled the following list of modifications that were necessary to
pass the JCK tests. There are a lot more suspicious uses of getBytes(),
where we were not able to decide whether their usage is right or wrong.

ACTION ITEM:
Please initiate some kind of overall review of the encoding issue,
and fix all java classes where the problem occurs.

=== Start of list ===

The method getBytes() in java.lang.String converts implictly with native
encoding. The usage of this method on machines where native encoding is
not ISO-8859-1 or some compatible ASCII encoding is wrong in J2SE SDK
1.4.2 in the following cases.

sun/tools/javazic/Gen.java
// all occurrences of getBytes() have to be changed to
// getBytes("US-ASCII") because in sun/util/calendar/ZoneInfoFile.java
// the file is read with US-ASCII encoding

=== end of list ===