db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sunitha Kambhampati (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-900) Remove use of String(byte[]) and String(byte[], int, int) constructors in network client leading to non-portable behaviour
Date Tue, 25 Apr 2006 18:25:04 GMT
     [ http://issues.apache.org/jira/browse/DERBY-900?page=all ]

Sunitha Kambhampati updated DERBY-900:
--------------------------------------

    Attachment: derby900.p2.stat.txt
                Derby900.p2.diff.txt

With the changes checked in for DERBY-1127, now, there are 3 places where non portable String.getBytes()
is used in client which is in NetConnectionReply.parseSQLDCGRP

This patch(Derby900.p2.diff.txt)  removes use of this non portable method from the client
and does some cleanup as part of removing usage of the String.getBytes() method.


Explanation of changes :
-- Server sends SQLSTATE in UTF8 encoding.

-- see below code snippet ( taken from parseSQLDCGRP )
       int sqldcCode = readFastInt(); // SQLCODE
**********
        String sqldcState = readFastString(5, netAgent_.targetTypdef_.getCcsidSbcEncoding());
// SQLSTATE
***********
        int sqldcReason = readFastInt();  // REASON_CODE
        int sqldcLinen = readFastInt(); // LINE_NUMBER
        int sqldcRown = (int) readFastLong(); // ROW_NUMBER

        // save +20237 in the 0th entry of the rowsetSqlca's.
        // this info is going to be used when a subsequent fetch prior is issued, and if already
        // received a +20237 then we've gone beyond the first row and there is no need to
        // flow another fetch to the server.
        if (sqldcCode == 20237) {
            rowsetSqlca[0] = new NetSqlca(netAgent_.netConnection_,
                    sqldcCode,
                    sqldcState.getBytes(),   //************
                    null,
                    netAgent_.targetTypdef_.getCcsidSbc());


Basically the sqldcState is read using UTF8 or netAgent_.targetTypdef_.getCcsidSbcEncoding()
and converted to a String and 
then converted back to bytes using the bad non portable getBytes().  In NetSqlca, the sqldcState
bytes and ccsid is passed in. The sqlstate bytes is set to sqldcState_ in NetSqlca and it
is decoded using UTF8 in getSQLState using the method Sqlca::bytes2String.

In short, the getBytes() should take UTF-8 encoding but it seems much cleaner to do the cleanup
here to avoid doing the extra conversion. currently conversion happens from bytes to string,
and then to bytes and then back to string.   

Cleanup includes:
--The ccsid in NetSqlca is never used and I have cleaned that up.
--NetSqlca takes in sqlstate as bytes and then is converted to string. Instead since we have
a string available already, there is no need of an extra conversion as seen in code snippet
above.  I have changed the NetSqlca constructor to take in 
the sqlstate as String.
-- There is one place where the sqlstate is retrieved as bytes and passed to the NetSqlca
constructor as such. I have overloaded the NetSqlca constructor to take in the sqlstate bytes
and convert it to a string in the constructor itself.
-- cleaned up Sqlca.getSQLState()

-- During the cleanup one thing odd was all or most of the method signatures in this codepath
have a throws DisconnectException even though some of them do not have any code that would
throw this exception. In any case I have not cleaned those instances as I think it might be
better to address them separately from this patch/issue.
-- The NetSqlca constructor that does the conversion of the sqlstate bytes to string will
throw a unsupportedencodingException that is thrown as a SqlException. This SqlException is
wrapped into a DisconnectException in parseSQLCAGRP.  I followed the same approach as Reply.readFastString()
that wraps the UnsupportedEncodingException into a DisconnectException. 

I think lots more encoding related cleanup can be done in client, but I will leave that for
DERBY-951.

This is a client only change and I ran derbynetclientmats on windows/jdk142 ok. I also ran
derbynetclientmats and derbynetmats on Z/OS with no new failures.  
I also ran the encodingTests with sun jdk1.5 OK.

Can someone please look at this change. Thanks. 

> Remove use of String(byte[]) and String(byte[], int, int) constructors in network client
leading to non-portable behaviour
> --------------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-900
>          URL: http://issues.apache.org/jira/browse/DERBY-900
>      Project: Derby
>         Type: Bug

>   Components: Network Client
>     Reporter: Daniel John Debrunner
>     Assignee: Sunitha Kambhampati
>      Fix For: 10.2.0.0
>  Attachments: Derby900.p2.diff.txt, TestEnc.java, derby900.diff.p1.txt, derby900.p2.stat.txt,
derby900.stat.p1.txt, derby900.test.diff.txt, derby900.test.stat.txt, for_10.1_derby900.diff.p1.txt,
for_10.1_derby900.stat.p1.txt
>
> 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.client.am.ClobOutputStream - some existing bug?
> org.apache.derby.client.am.DateTime - see DERBY-877
> org.apache.derby.client.am.sqlca
> I generated this list using the Java search in eclipse for references to the constructors
> String(byte[])
> String(byte[],int,int)

-- 
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


Mime
View raw message