JDK-6405064 : Undeprecate hibyte String constructors
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux
  • CPU: x86
  • Submitted: 2006-03-28
  • Updated: 2012-01-11
  • Resolved: 2006-07-21
Related Reports
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
Many Java libraries do not provide a CharSequence option in place of String arguments. I have byte arrays of ASCII text and I must first convert them to a String before passing them to such libraries. String(byte[] ascii, int hibyte)  and String(byte[] ascii, int hibyte, int offset, int count) provide the most efficient way to turn ASCII text into a string. It is unsettling that you have signalled that these constructors may be deleted in a future version of Java.

JUSTIFICATION :
The String(char[] value) constructors are an inefficient substitute because they must make _another_ copy of the char array to protect against mutation of the supplied char array. Only the deprecated constructors avoid the generation of an intermediate char array.

Note that the String constructors that take a charset String name are unacceptably inefficient because (a) the charset String name must first be parsed to determine the encoding and (b) the generic decoding process is unnecessary overhead.


CUSTOMER SUBMITTED WORKAROUND :
The workaround for avoiding the deprecated constructors is to first create a char array of ASCII text. This doubles the amount of copying and memory consumption.

Comments
EVALUATION It seems like the justification for undeprecating the "hibyte" constructors is that there are too many APIs which accept only String rather than CharSequence. The correct solution is to identify the key APIs which would benefit from adding parallel methods which take CharSequence. Please file bugs/rfes for these methods indicating why they are needed. It is highly unlikely that we will ever undeprecate these methods.
21-07-2006

EVALUATION It is true that when creating *small* strings containing only ASCII or Latin-1 characters, the deprecated constructor is the most efficient way. A number of developers have discovered this fact, and so there is a critical dependence on these constructors to continue working. There is a a good case for denigrating, rather than deprecating, these constructors. We could do more work on making Charset lookup and String construction more efficient, thereby removing the need for developers to use the hibyte constructor performance hack. Note that Americans/Western Europeans already enjoy many advantages, like getting front-row seats in the BMP. As a practical matter, these constructors will never be removed. Too many people would scream. See: 6402819: String(a, charset) slower than String(a, charsetname)
28-03-2006