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.
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.