Derby
  1. Derby
  2. DERBY-587

Providing JDBC 4.0 support for derby

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: 10.2.1.6
    • Component/s: JDBC
    • Labels:
      None
    1. jdbc4.diff
      150 kB
      V.Narayanan
    2. jdbc4.0.sxw
      10 kB
      V.Narayanan
    3. bug587_javadoc.diff
      3 kB
      Rick Hillegas

      Activity

      Hide
      V.Narayanan added a comment -

      Hi,
      I am attaching the patch for the JDBC4.0 STUB IMPLEMENTATION. Also attached is a design document which explains the changes incorporated and the classes and the build files affected due to this.
      thanx
      V.Narayanan

      Show
      V.Narayanan added a comment - Hi, I am attaching the patch for the JDBC4.0 STUB IMPLEMENTATION. Also attached is a design document which explains the changes incorporated and the classes and the build files affected due to this. thanx V.Narayanan
      Hide
      V.Narayanan added a comment -

      Hi,
      There was a small problem in the previous patch while doing a svn diff. Also the document has been updated to reflect that the jdk16 variable is optional. I am making the changes and attaching the files again.
      thanx
      Narayanan

      Show
      V.Narayanan added a comment - Hi, There was a small problem in the previous patch while doing a svn diff. Also the document has been updated to reflect that the jdk16 variable is optional. I am making the changes and attaching the files again. thanx Narayanan
      Hide
      Rick Hillegas added a comment -

      This patch looks good to me. I recommend that a committer check it in.

      Show
      Rick Hillegas added a comment - This patch looks good to me. I recommend that a committer check it in.
      Hide
      Oyvind Bakksjo added a comment -

      OK, I'll commit it.

      Show
      Oyvind Bakksjo added a comment - OK, I'll commit it.
      Hide
      Daniel John Debrunner added a comment -

      The document says that EmbeddedDataSource40 extends EmbeddedDataSource30, but there is no such class in Derby.
      In fact this EmbeddedDataSource40 looks like it has to become part of the public api, which means a shift in Derby from a single class for JDBC 2.0 and JDBC 3.0, to applications having to select a specific DataSource for JDBC 4.0.
      Not sure this is a problem for this check in, but it might be something that needs to be resolved before a Derby release is made that supports JDBC 4.0. E.g. if the DataSource doesn't change in JDBC 5.0 then do applications still need to load EmbeddedDataSource40, possibly leading to confusion?

      One minor issue with the patch, the new constant in JVMInfo for JDK 1.6 has the comment aka J2SE 5.0 which is the same as JDK 1.5. Is that true?

      Show
      Daniel John Debrunner added a comment - The document says that EmbeddedDataSource40 extends EmbeddedDataSource30, but there is no such class in Derby. In fact this EmbeddedDataSource40 looks like it has to become part of the public api, which means a shift in Derby from a single class for JDBC 2.0 and JDBC 3.0, to applications having to select a specific DataSource for JDBC 4.0. Not sure this is a problem for this check in, but it might be something that needs to be resolved before a Derby release is made that supports JDBC 4.0. E.g. if the DataSource doesn't change in JDBC 5.0 then do applications still need to load EmbeddedDataSource40, possibly leading to confusion? One minor issue with the patch, the new constant in JVMInfo for JDK 1.6 has the comment aka J2SE 5.0 which is the same as JDK 1.5. Is that true?
      Hide
      Rick Hillegas added a comment -

      I retract my hasty judgment. I don't think this submission is ready to be committed. The good news is that the trunk compiles without jdk1.6 and derbyall runs cleanly--I think. I saw a diff in NSinSameJVM but I think I may have seen this intermittently on my machine before.

      However, compilation fails when I define jdk16 in my ant.properties. The compilation will not run under cygwin. I almost have a fix for this but I'm not quite there yet. So let's hold off committing this.

      Show
      Rick Hillegas added a comment - I retract my hasty judgment. I don't think this submission is ready to be committed. The good news is that the trunk compiles without jdk1.6 and derbyall runs cleanly--I think. I saw a diff in NSinSameJVM but I think I may have seen this intermittently on my machine before. However, compilation fails when I define jdk16 in my ant.properties. The compilation will not run under cygwin. I almost have a fix for this but I'm not quite there yet. So let's hold off committing this.
      Hide
      Rick Hillegas added a comment -

      Dan raises an uncomfortable issue which I hope we don't have to address for this submission but which we do have to address for the 10.2 release. EmbeddedDataSource is just one instance of the problem. But it surfaces across the org.apache.derby.jdbc package.

      The problem is that EmbeddedDataSource implements an interface (javax.sql.DataSource) which has changed between jdk1.4 and jdk1.6 in an irreconcilable way. In jdk1.6, DataSource contains a method with generics in its signature. If we ship an EmbeddedDataSource which implements this method, then I think it won't play well in a 1.4 vm. If, however, we ship an EmbeddedDataSource which does NOT implement this method, then on a 1.6 vm, EmbeddedDataSource will fail to satisfy the DataSource contract.

      Here are some ways we could solve this problem:

      1) Ship both a 1.4 and a 1.6 version of EmbeddedDataSource and sort the problem out at run time using some kind of classloader jiggery pokery. I'm waving my hands because I don't understand what the jiggery pokery would be.

      2) Release two different distributions of 10.2, one for 1.5 and earlier vms and another for 1.6 vms.

      3) Deprecate EmbeddedDataSource as a class in 10.2. Instead, turn it into an interface and add a factory to org.apache.derby.jdbc which is smart enough to contruct a vm-specific class at runtime. This solution could be applied to the other classes in that package which have the same problem.

      Show
      Rick Hillegas added a comment - Dan raises an uncomfortable issue which I hope we don't have to address for this submission but which we do have to address for the 10.2 release. EmbeddedDataSource is just one instance of the problem. But it surfaces across the org.apache.derby.jdbc package. The problem is that EmbeddedDataSource implements an interface (javax.sql.DataSource) which has changed between jdk1.4 and jdk1.6 in an irreconcilable way. In jdk1.6, DataSource contains a method with generics in its signature. If we ship an EmbeddedDataSource which implements this method, then I think it won't play well in a 1.4 vm. If, however, we ship an EmbeddedDataSource which does NOT implement this method, then on a 1.6 vm, EmbeddedDataSource will fail to satisfy the DataSource contract. Here are some ways we could solve this problem: 1) Ship both a 1.4 and a 1.6 version of EmbeddedDataSource and sort the problem out at run time using some kind of classloader jiggery pokery. I'm waving my hands because I don't understand what the jiggery pokery would be. 2) Release two different distributions of 10.2, one for 1.5 and earlier vms and another for 1.6 vms. 3) Deprecate EmbeddedDataSource as a class in 10.2. Instead, turn it into an interface and add a factory to org.apache.derby.jdbc which is smart enough to contruct a vm-specific class at runtime. This solution could be applied to the other classes in that package which have the same problem.
      Hide
      V.Narayanan added a comment -

      The patch has been fixed for the failure in windows and re-attached.

      Show
      V.Narayanan added a comment - The patch has been fixed for the failure in windows and re-attached.
      Hide
      Rick Hillegas added a comment -

      The patch looks good. Derby builds cleanly. If you put a pointer to jdk16 into your ant.properties, Derby again builds cleanly, including the new jdbc4 stubbed out implementation. Derbyall runs cleanly on my machine under jdk14. Under jdk16, the new jdbc4 tests run cleanly.

      I recommend that a committer commit this patch. Note that the committer will need to svn_add the following five empty master files:

      svn_add trunk/java/testing/org/apache/derbyTesting/functionTests/master/StartTestConnection.out
      svn_add trunk/java/testing/org/apache/derbyTesting/functionTests/master/TestCallableStatementMethods.out
      svn_add trunk/java/testing/org/apache/derbyTesting/functionTests/master/TestConnectionMethods.out
      svn_add trunk/java/testing/org/apache/derbyTesting/functionTests/master/TestPreparedStatementMethods.out
      svn_add trunk/java/testing/org/apache/derbyTesting/functionTests/master/TestResultSetMethods.out

      Show
      Rick Hillegas added a comment - The patch looks good. Derby builds cleanly. If you put a pointer to jdk16 into your ant.properties, Derby again builds cleanly, including the new jdbc4 stubbed out implementation. Derbyall runs cleanly on my machine under jdk14. Under jdk16, the new jdbc4 tests run cleanly. I recommend that a committer commit this patch. Note that the committer will need to svn_add the following five empty master files: svn_add trunk/java/testing/org/apache/derbyTesting/functionTests/master/StartTestConnection.out svn_add trunk/java/testing/org/apache/derbyTesting/functionTests/master/TestCallableStatementMethods.out svn_add trunk/java/testing/org/apache/derbyTesting/functionTests/master/TestConnectionMethods.out svn_add trunk/java/testing/org/apache/derbyTesting/functionTests/master/TestPreparedStatementMethods.out svn_add trunk/java/testing/org/apache/derbyTesting/functionTests/master/TestResultSetMethods.out
      Hide
      Satheesh Bandaram added a comment -

      I noticed Narayanan doesn't have ICLA signed with Apache. Any "reasonable" size contribution would require the contributor to have an ICLA signed and be on file. List of ICLAs can be found at: http://people.apache.org/~jim/committers.html. The process of starting an ICLA submission: http://www.apache.org/licenses/#clas

      I think it is wise to hold off on checking this in, pending ICLA submission. I was so close...

      Several new JAVA files don't have the ASF copyright notices at the top ... Isn't this required for all new JAVA files?

      I also noticed an @author tag in the patch. While I am not sure what guidelines Apache or Derby follows, it may be best to remove @author tags. Geronimo has a policy against this tag: http://wiki.apache.org/geronimo/CodingStandards

      One last minor one... The copyright notice should have 2005 for the file jdk16.java

      Show
      Satheesh Bandaram added a comment - I noticed Narayanan doesn't have ICLA signed with Apache. Any "reasonable" size contribution would require the contributor to have an ICLA signed and be on file. List of ICLAs can be found at: http://people.apache.org/~jim/committers.html . The process of starting an ICLA submission: http://www.apache.org/licenses/#clas I think it is wise to hold off on checking this in, pending ICLA submission. I was so close... Several new JAVA files don't have the ASF copyright notices at the top ... Isn't this required for all new JAVA files? I also noticed an @author tag in the patch. While I am not sure what guidelines Apache or Derby follows, it may be best to remove @author tags. Geronimo has a policy against this tag: http://wiki.apache.org/geronimo/CodingStandards One last minor one... The copyright notice should have 2005 for the file jdk16.java
      Hide
      Rick Hillegas added a comment -

      Thanks for pointing out these issues, Satheesh. I didn't turn up on the published list until a couple months after I submitted my ICLA. I'm hoping that it will be sufficient for Narayanan to say that he has faxed in his ICLA. That is, I hope we don't have to wait another 2 months to contribute this patch.

      Show
      Rick Hillegas added a comment - Thanks for pointing out these issues, Satheesh. I didn't turn up on the published list until a couple months after I submitted my ICLA. I'm hoping that it will be sufficient for Narayanan to say that he has faxed in his ICLA. That is, I hope we don't have to wait another 2 months to contribute this patch.
      Hide
      Rick Hillegas added a comment -

      Hi Satheesh: Narayanan has faxed in his ICLA. He's on holiday (Diwali) right now. Would it be ok to clean up the copyright and tag issues later? If so, would you be kind enough to check in this patch today? Thanks!

      Show
      Rick Hillegas added a comment - Hi Satheesh: Narayanan has faxed in his ICLA. He's on holiday (Diwali) right now. Would it be ok to clean up the copyright and tag issues later? If so, would you be kind enough to check in this patch today? Thanks!
      Hide
      Satheesh Bandaram added a comment -

      As Dan (PMC member) said, we have to wait for the copyright notices for the files... Also, it would be good if Narayanan himself can post whether or not he FAXed his ICLA.

      Show
      Satheesh Bandaram added a comment - As Dan (PMC member) said, we have to wait for the copyright notices for the files... Also, it would be good if Narayanan himself can post whether or not he FAXed his ICLA.
      Hide
      V.Narayanan added a comment -

      Hi,
      Thanx for pointing out the issues satheesh. Also thanx for the follow up email address jean. I faxed the agreement to apache yesterday. Also I will follow this up using the email address given by jean. Sorry for my late response.
      Narayanan

      Show
      V.Narayanan added a comment - Hi, Thanx for pointing out the issues satheesh. Also thanx for the follow up email address jean. I faxed the agreement to apache yesterday. Also I will follow this up using the email address given by jean. Sorry for my late response. Narayanan
      Hide
      Craig L Russell added a comment -

      I recognize that this is an internal project issue, but:

      Doesn't the "grant Apache license" check box on the patch upload mean anything? I always assumed that it allowed someone without an ICLA on file to contribute code. The patches uploaded for this bug have the "grant Apache license" checked...Of course, the copyright notices are required in the code for new files.

      Craig

      Show
      Craig L Russell added a comment - I recognize that this is an internal project issue, but: Doesn't the "grant Apache license" check box on the patch upload mean anything? I always assumed that it allowed someone without an ICLA on file to contribute code. The patches uploaded for this bug have the "grant Apache license" checked...Of course, the copyright notices are required in the code for new files. Craig
      Hide
      Daniel John Debrunner added a comment -

      I think this is an Apache wide issue, or desire:

      http://www.apache.org/licenses/#clas

      "The ASF desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit (via snailmail or fax) a Individual Contributor License Agreement (CLA)"

      Show
      Daniel John Debrunner added a comment - I think this is an Apache wide issue, or desire: http://www.apache.org/licenses/#clas "The ASF desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit (via snailmail or fax) a Individual Contributor License Agreement (CLA)"
      Hide
      Craig L Russell added a comment -

      I have just a few comments.

      1. The code does not appear to be consistent with regard to spaces, tabs, indents, and which line the "{" appears on. Are there coding standards to which we try to hold contributions? Other projects recognize that some files in the same project use different coding styles (standards?) but try to maintain standards for new files. The rule is that patches to existing files use the conventions already used, but new files have a standard approach. Are there any such standards for Derby?

      2. The copyright notices definitely need to be there for this contribution.

      3. I agree that for a contribution of this magnitude, a signed ICLA should be a requirement.

      4. In response to Dan's comments immediately above, I'd think that the Apache board might want to discuss why the JIRA has a check box for contributions. If it's really irrelevant, it's certainly a distraction.

      Show
      Craig L Russell added a comment - I have just a few comments. 1. The code does not appear to be consistent with regard to spaces, tabs, indents, and which line the "{" appears on. Are there coding standards to which we try to hold contributions? Other projects recognize that some files in the same project use different coding styles (standards?) but try to maintain standards for new files. The rule is that patches to existing files use the conventions already used, but new files have a standard approach. Are there any such standards for Derby? 2. The copyright notices definitely need to be there for this contribution. 3. I agree that for a contribution of this magnitude, a signed ICLA should be a requirement. 4. In response to Dan's comments immediately above, I'd think that the Apache board might want to discuss why the JIRA has a check box for contributions. If it's really irrelevant, it's certainly a distraction.
      Hide
      V.Narayanan added a comment -

      Hi,
      I am making the following changes and am re-attaching the patch

      1) Adding of copyright notices
      2) reformatting code

      Also I have faxed and sent my ICLA by post to apache.
      I am waiting to hear from Apache regarding my ICLA. I have faxed the ICLA a couple of times and also mailed(snail-mail) it to them
      I have also sent follow up email to apache@apache.org and am waiting for a response from them.

      thanx
      V.Narayanan

      Show
      V.Narayanan added a comment - Hi, I am making the following changes and am re-attaching the patch 1) Adding of copyright notices 2) reformatting code Also I have faxed and sent my ICLA by post to apache. I am waiting to hear from Apache regarding my ICLA. I have faxed the ICLA a couple of times and also mailed(snail-mail) it to them I have also sent follow up email to apache@apache.org and am waiting for a response from them. thanx V.Narayanan
      Hide
      Rick Hillegas added a comment -

      I have successfully built this patch under jdk1.4 and jdk1.6. For me derbyall runs cleanly under jdk1.4. Under jdk1.6 the new jdbc4 tests run cleanly.

      Satheesh, when you have a moment, could you verify that this submission satisifies the copyright and formatting issues you raised? If so, and there are no new issues, then I think this is ready to be committed.

      Show
      Rick Hillegas added a comment - I have successfully built this patch under jdk1.4 and jdk1.6. For me derbyall runs cleanly under jdk1.4. Under jdk1.6 the new jdbc4 tests run cleanly. Satheesh, when you have a moment, could you verify that this submission satisifies the copyright and formatting issues you raised? If so, and there are no new issues, then I think this is ready to be committed.
      Hide
      Satheesh Bandaram added a comment -

      Thanks, Narayanan, for the follow up. I think only the ICLA is the pending issue now. Jean had mentioned last time that either your name show on the list or get some kind of acknowledgement that Apache received your fax. I will commit your changes just after that.

      Jean, let us know if there is any other way. I hate to be holding up good and important work, but don't know what else I could do.

      Thanks to Rick for the reviews and for running the tests.

      Show
      Satheesh Bandaram added a comment - Thanks, Narayanan, for the follow up. I think only the ICLA is the pending issue now. Jean had mentioned last time that either your name show on the list or get some kind of acknowledgement that Apache received your fax. I will commit your changes just after that. Jean, let us know if there is any other way. I hate to be holding up good and important work, but don't know what else I could do. Thanks to Rick for the reviews and for running the tests.
      Hide
      Jean T. Anderson added a comment -

      Narayanan's icla now shows up as being recorded – so go ahead and commit, Satheesh.

      Show
      Jean T. Anderson added a comment - Narayanan's icla now shows up as being recorded – so go ahead and commit, Satheesh.
      Hide
      Satheesh Bandaram added a comment -

      I have submitted this patch. Thanks everyone!

      Show
      Satheesh Bandaram added a comment - I have submitted this patch. Thanks everyone!
      Hide
      Rick Hillegas added a comment -

      The original patch broke javadoc generation because the 1.4 javadoc machinery doesn't understand the 1.6 signatures which contain generics. I have attached bug587_javadoc.diff to fix this regression. Thanks to Dyre for tripping across the problem.

      Show
      Rick Hillegas added a comment - The original patch broke javadoc generation because the 1.4 javadoc machinery doesn't understand the 1.6 signatures which contain generics. I have attached bug587_javadoc.diff to fix this regression. Thanks to Dyre for tripping across the problem.
      Hide
      David Van Couvering added a comment -

      Committed fix for javadoc

      $ svn commit
      Sending build.xml
      Transmitting file data .
      Committed revision 348203.

      Show
      David Van Couvering added a comment - Committed fix for javadoc $ svn commit Sending build.xml Transmitting file data . Committed revision 348203.
      Hide
      Andrew McIntyre added a comment -

      David - it looks like you missed the derbydocs_exclusions.ant file in the javadoc fix patch. I've checked it in with revision 350292.

      It's unfortunate that it's now necessary to copy basically the entire source tree, almost 1700 files, to generate the javadoc. But, since javadoc itself doesn't have the ability to exclude a list of files, only packages, I don't know what else to do either. If anyone knows a way to get Ant to generate a list of files (like the find command) that we could then filter, let me know.

      Show
      Andrew McIntyre added a comment - David - it looks like you missed the derbydocs_exclusions.ant file in the javadoc fix patch. I've checked it in with revision 350292. It's unfortunate that it's now necessary to copy basically the entire source tree, almost 1700 files, to generate the javadoc. But, since javadoc itself doesn't have the ability to exclude a list of files, only packages, I don't know what else to do either. If anyone knows a way to get Ant to generate a list of files (like the find command) that we could then filter, let me know.
      Hide
      Andrew McIntyre added a comment -

      This issue has been resolved for over a year with no further movement. Closing.

      Show
      Andrew McIntyre added a comment - This issue has been resolved for over a year with no further movement. Closing.

        People

        • Assignee:
          V.Narayanan
          Reporter:
          V.Narayanan
        • Votes:
          1 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development