JDK-4937512 : com.sun.jndi.ldap.Filter uses String.getBytes - native enc incorrectly assumed
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.naming
  • Affected Version: 1.4.2,5.0u4
  • Priority: P5
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2003-10-14
  • Updated: 2017-10-31
  • Resolved: 2017-10-31
Related Reports
Duplicate :  
JDK-4927428 - String.getBytes() is used in many places - native encoding incorrectly assumed
Relates :  
JDK-6328469 - encoding bug (6317399): com/sun/jndi/ldap/Filter.java
Description
This is the jndi 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.

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"));

=== end of list ===
Comments
mentioned issue is already fixed as part of some other code change. I checked the recent code and did not found the problematic code.
31-10-2017
SUGGESTED FIX From 6317399: com/sun/jndi/ldap/Filter.java ----------------------------- // wrong line 433 dprint(", type: ", Integer.toString(filterType, 16).getBytes()); // correction: dprint(", type: ", Integer.toString(filterType, 16).getBytes("ISO-8859-1"));
25-09-2005
EVALUATION The above is correct, so I'm reopening this CR.
25-09-2005
EVALUATION > The dprint method is debug code, and is not designed to > handle arbitrary encodings or multi-byte characters or > non-platform-default encodings. Customer doesn't agree and believes that there is still a bug, because the same conversion is done twice, which leads to unreadable results. First there is a conversion to EBCDIC (our native encoding) done by Integer.toString(filterType, 16).getBytes(), then in dprint line 622 there is a cast (not a conversion!) to char which then is again converted to EBCDIC by the write-method. Customer is sure that the original code leads to wrong results, and that the suggested fix (6328469) works.
24-09-2005
EVALUATION The fix is being added. There are no other such occurances in the JNDI codebase. ###@###.### 2003-10-16 The LDAP provider is not tested by JCK, so the mention of JCK in the description section is misleading. The String.getBytes() call in question occurs in debug code, so the priority should be lowered accoringly. The justification section may be appropriate for the umbrella bug report from which this one is derived, but certainly doesn't apply to this bug report. The debug code in question converts a string to bytes using the platform-default encoding, and then prints it back out in the dprint method. The dprint method is debug code, and is not designed to handle arbitrary encodings or multi-byte characters or non-platform-default encodings. In short, I'd say that the String.getBytes call is not a bug at all, and the suggested fix would itself create a bug. ###@###.### 2003-10-15
15-10-2003