[ http://issues.apache.org/jira/browse/DERBY-1180?page=comments#action_12375558 ]
Kristian Waagan commented on DERBY-1180: ---------------------------------------- All the comments are valid, but since I am only adding placeholders that throw not implemented exceptions, I decided to not document the methods. In my opinion, this should be done when the methods are implemented for two reasons: the JavaDoc might have changed (JDBC 4 spec flexing) and there might be implementation specifc notes. The person implementing the methods must take a stand regarding the information duplication with regards to the interface. createBlob/-Clob where placed in the JDBC 4 specific class to make it easier to see that they are JDBC 4 methods. When they are implemented, they should be moved if appropriate. An exception to this, is the isClosed method of the Brokered* classes, where I placed it in the superclass to avoid having to add several vacuous implementations. Again, this will be handled when the method is actually implemented. If the methods cannot be in the "generic" class (non-JDBC 4 specifc) and there are no JDBC 4 specific class, I must create one to not break the build. Unless I get pushback on my approach, I will follow it for the Derby client side as well. > Add vacuous implementations of missing JDBC4 methods > ---------------------------------------------------- > > Key: DERBY-1180 > URL: http://issues.apache.org/jira/browse/DERBY-1180 > Project: Derby > Type: New Feature > Components: JDBC > Versions: 10.2.0.0 > Reporter: Rick Hillegas > Assignee: Kristian Waagan > Attachments: bug1180_1.diff, bug1180_embeddedStarter.diff, > derby-1180-1a-embedded.diff, derby-1180-1a-embedded.stat > > If you run the VerifySignatures test, you will see a lot of JDBC4 methods > which don't appear in our implementation yet. We need to add vacuous > implementations for these methods which raise > SQLFeatureNotSupportedExceptions. Most of these methods won't need any more > attention because they refer to features (like xml and national strings) > which we don't support. We will open additional JIRAs for the methods which > need non-vacuous implementations. -- 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
