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.


com/sun/jndi/ldap/Filter.java
// wrong line 411
dprint(", type: ", Integer.toString(filterType, 16).getBytes());
// correction:
dprint(", type: ", Integer.toString(filterType, 16).getBytes("ISO-8859-1"));


com/sun/security/auth/module/Crypt.java
// wrong line 376
byte result[] = c.crypt(arg[0].getBytes(), arg[1].getBytes());
// correction:
byte result[] = null;
try {
result = c.crypt(arg[0].getBytes("ISO-8859-1"), arg[1].getBytes("ISO-8859-1"));
} catch (java.io.UnsupportedEncodingException dummyexc) {
// cannot happen
}


com/sun/security/auth/module/JndiLoginModule.java
// wrong lines 716 - 718
byte oldCrypt[] = encryptedPassword.getBytes();
byte newCrypt[] = c.crypt(password.getBytes(),
oldCrypt);
// correction (we use UTF8 as the string was generated with UTF8):
byte oldCrypt[] = null;
byte newCrypt[] = null;
try {
oldCrypt = encryptedPassword.getBytes("UTF8");
newCrypt = c.crypt(password.getBytes("UTF8"),
oldCrypt);
} catch (java.io.UnsupportedEncodingException dummyexc) {
// cannot happen
}


java/beans/XMLEncoder.java
// wrong line 464
            out.write(" \n".getBytes());
// correction:
out.write(" \n".getBytes(encoding));


java/net/SocksSocketImpl.java
// all occurrences of getBytes() have to be changed to
// getBytes("ISO-8859-1")


sun/net/www/protocol/http/BasicAuthentication.java
// wrong lines 42 and 76
byte[] nameBytes = plain.getBytes();
// correction:
byte[] nameBytes = null;
try {
nameBytes = plain.getBytes("ISO-8859-1");
} catch (java.io.UnsupportedEncodingException dummyexc) {
// cannot happen
}

              
sun/net/www/protocol/http/DigestAuthentication.java
// wrong line 488
md.update(src.getBytes());
// correction:
try {
md.update(src.getBytes("ISO-8859-1"));
} catch (java.io.UnsupportedEncodingException dummyexc) {
// cannot happen
}

sun/security/util/DerOutputStream.java
// wrong line 475
        byte[] time = (sdf.format(d)).getBytes();
// correction:
        byte[] time = (sdf.format(d)).getBytes("ISO-8859-1");


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



The class InputStreamReader implicitly converts from native encoding. As certificates
are encoded in ASCII encoding, the following class must be corrected:

sun/security/provider/X509Factory.java
// wrong line 606
BufferedReader br = new BufferedReader(new InputStreamReader(bufin));
// correction:
BufferedReader br = new BufferedReader(new InputStreamReader(bufin,"ASCII"));

=== end of list ===