Derby
  1. Derby
  2. DERBY-5868

Move java.sql.Wrapper implementations to base classes on the client

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.10.1.1
    • Fix Version/s: 10.10.1.1
    • Component/s: JDBC
    • Labels:
      None

      Description

      The client classes that implement java.sql.Wrapper, implement the interface in the leaf classes instead of the base classes. This is because unwrap() has a generic signature, so it could not be in the base classes as long as they had to be compatible with Java 1.4.

      For example, in the statement class hierarchy, we implement unwrap() in Statement40, PreparedStatement40 and CallableStatement40. Now that we compile the client with source level 1.5, we can move the unwrap() method to the Statement class and eliminate the duplication.

      1. derby-5868-1a.patch
        55 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          Attaching a patch, derby-5868-1a.patch, that moves the isWrapperFor()
          and unwrap() implementations

          • from Statement40, PreparedStatement40 and CallableStatement40 to Statement
          • from LogicalPreparedStatement40 and LogicalCallableStatement40 to
            LogicalStatementEntity
          • from ClientDataSource40, ClientConnectionPoolDataSource40 and
            ClientXADataSource40 to ClientDataSource
          • from ColumnMetaData40 to ColumnMetaData
          • from ParameterMetaData40 to ParameterMetaData

          (The patch also moves some methods that had identical implementations in
          PreparedStatement40 and CallableStatement40 to PreparedStatement.)

          The above modifications allowed removal of the following classes, as they no
          longer contained any methods, except constructors that forwarded their arguments
          to the parent class:

          • Statement40, ColumnMetaData40 and ParameterMetaData40

          Because of the removals, ClientJDBCObjectFactoryImpl40 had to be adjusted to
          return plain Statement, ColumnMetaData and ParameterMetaData instances instead.

          Another consequence of these changes is that all the client data sources now
          implement the JDBC 4.0 interface, so one doesn't have to use the data sources
          whose names end with "40" to call JDBC 4.0 methods (of course, one can still use
          those data sources too). I've updated the class javadoc for the data sources to
          say just that.

          There is a test, JDBC4FromJDBC3DataSourceTest, that tests explicitly that
          calling JDBC 4.0 methods on a data source whose class name does not end with
          "40", fails. This test had to be updated to not expect failure when running
          against the client data sources.

          I have only run the jdbc4 test suite on the patch so far. Will run the full
          regression test suite on Java 5, 6 and 7.

          It probably makes sense to make similar changes on the embedded side, but first
          we'd need to make the JDBC 3.0 embedded interfaces compile with source level
          1.5.

          Show
          Knut Anders Hatlen added a comment - Attaching a patch, derby-5868-1a.patch, that moves the isWrapperFor() and unwrap() implementations from Statement40, PreparedStatement40 and CallableStatement40 to Statement from LogicalPreparedStatement40 and LogicalCallableStatement40 to LogicalStatementEntity from ClientDataSource40, ClientConnectionPoolDataSource40 and ClientXADataSource40 to ClientDataSource from ColumnMetaData40 to ColumnMetaData from ParameterMetaData40 to ParameterMetaData (The patch also moves some methods that had identical implementations in PreparedStatement40 and CallableStatement40 to PreparedStatement.) The above modifications allowed removal of the following classes, as they no longer contained any methods, except constructors that forwarded their arguments to the parent class: Statement40, ColumnMetaData40 and ParameterMetaData40 Because of the removals, ClientJDBCObjectFactoryImpl40 had to be adjusted to return plain Statement, ColumnMetaData and ParameterMetaData instances instead. Another consequence of these changes is that all the client data sources now implement the JDBC 4.0 interface, so one doesn't have to use the data sources whose names end with "40" to call JDBC 4.0 methods (of course, one can still use those data sources too). I've updated the class javadoc for the data sources to say just that. There is a test, JDBC4FromJDBC3DataSourceTest, that tests explicitly that calling JDBC 4.0 methods on a data source whose class name does not end with "40", fails. This test had to be updated to not expect failure when running against the client data sources. I have only run the jdbc4 test suite on the patch so far. Will run the full regression test suite on Java 5, 6 and 7. It probably makes sense to make similar changes on the embedded side, but first we'd need to make the JDBC 3.0 embedded interfaces compile with source level 1.5.
          Hide
          Knut Anders Hatlen added a comment -

          Derbyall and suites.All passed on Java 5, 6 and 7 with the patch.

          Show
          Knut Anders Hatlen added a comment - Derbyall and suites.All passed on Java 5, 6 and 7 with the patch.
          Hide
          Knut Anders Hatlen added a comment -

          Committed revision 1364042.

          Show
          Knut Anders Hatlen added a comment - Committed revision 1364042.

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development