[
http://issues.apache.org/jira/browse/DERBY-902?page=comments#action_12366690 ]
Daniel John Debrunner commented on DERBY-902:
---------------------------------------------
I'm not sure what comment you are reacting to, but my point was that there is
no need to use String.getBytes() to generate the String we need and thus have
to throw a UnsupportedEncoding exception.
The string created with the ascii encoding is the same as
char[] sepChars = { (char) 20, (char) 20, (char) 20};
new String(sepChars)
This is really the same as both your options, or a combination of them :-)
If we don't like the use of these ASCII control characters then as you say it
can be anything else.
Just to confirm, the contents of this String never make it across the wire to
the client?
> Remove use of String(byte[]) and String(byte[], int, int) constructors in
> engine leading to non-portable behaviour
> ------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-902
> URL: http://issues.apache.org/jira/browse/DERBY-902
> Project: Derby
> Type: Bug
> Components: Network Server
> Reporter: Daniel John Debrunner
> Fix For: 10.2.0.0
> Attachments: DERBY-902_021306.stat, DERBY-902_021306_2.diff
>
> These constructors use the Java default platform encoding to convert the
> bytes to a String, this typically leads to bugs on platforms with different
> encodings.
> Replace with code using fixed conversion, or alternative mechanisms.
> If the call is required its use should be commented as to why it is required.
> org.apache.derby.catalog.SystemProcedures
> I generated this list using the Java search in eclipse for references to the
> constructors
> String(byte[])
> String(byte[],int,int) - no occurrrences in java/engine
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
