Details

    • Sub-task
    • Status: Closed
    • Major
    • Resolution: Won't Fix
    • None
    • None
    • Build tools, Services
    • None

    Description

      Foundation 1.1 maps to a subset of JDK 1.4 so might be a better base for J2ME once JDK 1.3 support is removed, since Foundation 1.0 is based upon JDK 1.3. Foundation 1.1 is backward compatible with 1.0, so JSR169 is supported.

      Foundation 1.0 (JSR219) went final 19 Aug, 2005.
      http://jcp.org/en/jsr/detail?id=219

      Would allow use throughout the codeline initCause() for Throwable.

      Attachments

        Issue Links

          Activity

            Foundation 1.1 adds BigDecimal which breaks the assumption made by the current Derby JSR169 code that BigDecimal is not available. The combination of running with BigDecimal and JSR169 causes some issues in the code where SQLDecimal is used as the type for DECIMAL and tries to get/set values using get/setBigDecimal which are not supported by JSR 169.
            Dropping Foundation 1.0 support will allow use of BigDecimal as the underlying type for the internal DECIMAL data type thus dropping Derby's BigInteger implementation, but a split between the JDBC 3.0 and JSR 169 type will continue to be needed, due to the lack of setBigDecimal and getBigDecimal. This then requires some code shuffling in the datatypes implementation.

            djd Daniel John Debrunner added a comment - Foundation 1.1 adds BigDecimal which breaks the assumption made by the current Derby JSR169 code that BigDecimal is not available. The combination of running with BigDecimal and JSR169 causes some issues in the code where SQLDecimal is used as the type for DECIMAL and tries to get/set values using get/setBigDecimal which are not supported by JSR 169. Dropping Foundation 1.0 support will allow use of BigDecimal as the underlying type for the internal DECIMAL data type thus dropping Derby's BigInteger implementation, but a split between the JDBC 3.0 and JSR 169 type will continue to be needed, due to the lack of setBigDecimal and getBigDecimal. This then requires some code shuffling in the datatypes implementation.

            Thread on derby-user seeing if there is any concerns over removing support for Foundation 1.0

            http://mail-archives.apache.org/mod_mbox/db-derby-user/200701.mbox/%3c45A508AF.4020707@apache.org%3e

            djd Daniel John Debrunner added a comment - Thread on derby-user seeing if there is any concerns over removing support for Foundation 1.0 http://mail-archives.apache.org/mod_mbox/db-derby-user/200701.mbox/%3c45A508AF.4020707@apache.org%3e

            No concerns have been raised in two weeks over switching to 1.1 as the base level.

            djd Daniel John Debrunner added a comment - No concerns have been raised in two weeks over switching to 1.1 as the base level.

            The related issues DERBY-2228 and DERBY-2472 have been closed. What work remains to be done on this issue?

            rhillegas Richard N. Hillegas added a comment - The related issues DERBY-2228 and DERBY-2472 have been closed. What work remains to be done on this issue?

            The work described in the first comment relating to BigDecimal is still outstanding.

            djd Daniel John Debrunner added a comment - The work described in the first comment relating to BigDecimal is still outstanding.

            Thanks, Dan. What will this mean from the user's perspective? Perhaps:

            1) For DECIMAL types, when running on CDC/Foundation 1.1, ResultSet.getObject() and PreparedStatement.setObject() will operate on BigDecimal values?

            2) Something else?

            rhillegas Richard N. Hillegas added a comment - Thanks, Dan. What will this mean from the user's perspective? Perhaps: 1) For DECIMAL types, when running on CDC/Foundation 1.1, ResultSet.getObject() and PreparedStatement.setObject() will operate on BigDecimal values? 2) Something else?

            Can this issue be resolved/closed by now?

            The simplest way to confirm is maybe to run the tests with a with Foundation 1.1 VM (without JSR169 support), and to make sure the ParameterMappingTest is run/enabled? (it has been disabled for small platforms due to the BigDecimal issues)

            kristwaa Kristian Waagan added a comment - Can this issue be resolved/closed by now? The simplest way to confirm is maybe to run the tests with a with Foundation 1.1 VM (without JSR169 support), and to make sure the ParameterMappingTest is run/enabled? (it has been disabled for small platforms due to the BigDecimal issues)

            I don't think this can be resolved closed, as we never did anything about the assumption that running with the foundation means we don't have BigDecimal support at all.

            To take the ParameterMappingTest, if I enable the suite as is by commenting out the if (JDBC.vmSupportsJDBC3()) check, and run the test, I get the error as reported with DERBY-2403.
            If I in addition change the value if the 'HAVE_BIG_DECIMAL' to 'true' (e.g. by commenting out the check, or changing the value), I get the following error when running ParameterMappingTest:
            1) testParameterMapping(org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest)java.lang.NoSuchMethodError: java/sql/ResultSet.getBigDecimal(I)Ljava/math/BigDecimal;
            at org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.getXXX(ParameterMappingTest.java:1096)
            at org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.testParameterMapping(ParameterMappingTest.java:515)
            at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:195)
            at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112)
            at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
            at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
            at junit.extensions.TestSetup.run(TestSetup.java:23)
            at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

            It seems to me that somehow, to get this to work, we need to somehow be able to map BigDecimals as for other jvms, but when we encounter one of the methods that aren't supported (like ResultSet.getBigDecimal() and the like) we need to do something else than for other jvms.

            When this is resolved, we need to be able to run the ParameterMappingTest - see DERBY-2403.

            myrna Myrna van Lunteren added a comment - I don't think this can be resolved closed, as we never did anything about the assumption that running with the foundation means we don't have BigDecimal support at all. To take the ParameterMappingTest, if I enable the suite as is by commenting out the if (JDBC.vmSupportsJDBC3()) check, and run the test, I get the error as reported with DERBY-2403 . If I in addition change the value if the 'HAVE_BIG_DECIMAL' to 'true' (e.g. by commenting out the check, or changing the value), I get the following error when running ParameterMappingTest: 1) testParameterMapping(org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest)java.lang.NoSuchMethodError: java/sql/ResultSet.getBigDecimal(I)Ljava/math/BigDecimal; at org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.getXXX(ParameterMappingTest.java:1096) at org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.testParameterMapping(ParameterMappingTest.java:515) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:195) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) It seems to me that somehow, to get this to work, we need to somehow be able to map BigDecimals as for other jvms, but when we encounter one of the methods that aren't supported (like ResultSet.getBigDecimal() and the like) we need to do something else than for other jvms. When this is resolved, we need to be able to run the ParameterMappingTest - see DERBY-2403 .

            Java ME support has been removed on trunk, and I don't expect anyone is going to change the JSR-169 driver's BigDecimal handling on the older branches, so I'm closing this issue as won't fix.

            knutanders Knut Anders Hatlen added a comment - Java ME support has been removed on trunk, and I don't expect anyone is going to change the JSR-169 driver's BigDecimal handling on the older branches, so I'm closing this issue as won't fix.

            People

              Unassigned Unassigned
              djd Daniel John Debrunner
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: