Hi Knut, Rick, On Dec 22, 2010, at 6:02 AM, Knut Anders Hatlen (JIRA) wrote:
> > [ > https://issues.apache.org/jira/browse/DERBY-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974148#action_12974148 > ] > > Knut Anders Hatlen commented on DERBY-4869: > ------------------------------------------- > > Hi Rick, > > I looked at the getObject() patch. Some possible improvements: > > - For byte[], instead of doing a Class.forName("[B"), I think you > could check (type.isArray() && type.getComponentType().equals(byte.class)), > which would remove the need for catching/ignoring ClassNotFoundException. > > - Would it make sense to try getObject() unconditionally if no other > types match? Then the following code would work (I think) for most > numeric column types: > > Number num = rs.getObject("VALUE", Number.class); > > - The API javadoc explicitly mentions that type==null should result in > an SQLException. For completeness, add a test case for that? Agree > > - The API javadoc for Boolean, Byte, Short, Integer, Long, Float and > Double recommend the use of valueOf() instead of the constructor, as > valueOf() "is likely to yield significantly better space and time > performance". This change should definitely be made as there is a big performance improvement using valueOf > > - If the type conversion is not supported, an > SQLFeatureNotSupportedException is thrown. As far as I understand > the javadoc, this exception is reserved for the situation where the > method is not supported by the JDBC driver, which is not the case > here. If the conversion is not supported, a SQLException should be thrown: Throws: SQLException - if conversion is not supported, type is null or another error occurs. The getCause() method of the exception may provide a more detailed exception, for example, if a conversion error occurs SQLFeatureNotSupportedException - if the JDBC driver does not support this method > > - The client implementation makes closeCloseFilterInputStream() > non-private in order to call it from the new method. I think all the > getters called from the new getObject() method will call > closeCloseFilterInputStream(), so this code is probably not > necessary. > >> Implement JDBC 4.1, the api increment introduced by Java 7 >> ---------------------------------------------------------- >> >> Key: DERBY-4869 >> URL: https://issues.apache.org/jira/browse/DERBY-4869 >> Project: Derby >> Issue Type: Improvement >> Components: JDBC >> Reporter: Rick Hillegas >> Attachments: derby-4869-01-ac-rs-getObject.diff, >> derby-4869-02-aa-cs-ps-addBatch.diff, disable-tests.diff, >> JDBC_4.1_Changes.html >> >> >> This is a master issue logged to track our work implementing JDBC 4.1, the >> changes to the java.sql and javax.sql packages introduced by Java 7. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 [email protected] Oracle is committed to developing practices and products that help protect the environment
