Unsafe use of BigDecimal constructors
-------------------------------------
Key: DERBY-4892
URL: https://issues.apache.org/jira/browse/DERBY-4892
Project: Derby
Issue Type: Bug
Components: JDBC, Test
Affects Versions: 10.7.1.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
We have some code that's supposed to work on Java 1.4, but that uses BigDecimal
constructors that were not added until Java 5. The problematic constructors are
the ones that take a single int or long.
The constructors are used in the following classes:
org.apache.derby.client.am.Cursor
org.apache.derbyTesting.functionTests.tests.lang.Price
org.apache.derbyTesting.system.oe.client.Submitter
All of the classes are compiled against ${java14compile.classpath}, so one
would expect the build to fail when java14compile.classpath pointed to proper
Java 1.4 libraries. However, there is a constructor with a double parameter in
Java 1.4, and the compiler picks that constructor if it cannot find the ones
for int and long. If that happens, the compiled byte-code works on Java 1.4 and
newer, and everything is fine.
The problem appears when the build does not use the Java 1.4 libraries. This
can easily happen if you build without a customized ant.properties, and
PropertySetter ends up building java14compile.classpath based on the
auto-detected java15compile.classpath. In that case, the compiler finds the int
and long variants of the constructor, even when building against
java14compile.classpath. The compiled byte-code will therefore use those Java 5
constructors, and the code will fail at run-time if ever executed on a Java 1.4
JVM.
To reproduce, build Derby without ant.properties on a system where
PropertySetter doesn't find JDK 1.4. Verify with -DprintCompilerProperties=true
that java14compile.classpath is built up of jar files from a Java 5 or Java 6
directory. Then run org.apache.derbyTesting.functionTests.tests.lang.UDTTest
using a Java 1.4 JVM. You'll see two errors of this kind:
1)
test_06_casts(org.apache.derbyTesting.functionTests.tests.lang.UDTTest)java.lang.NoSuchMethodError:
java.math.BigDecimal.<init>(I)V
at
org.apache.derbyTesting.functionTests.tests.lang.Price.makePrice(Price.java:49)
at
org.apache.derbyTesting.functionTests.tests.lang.UDTTest.test_06_casts(UDTTest.java:501)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
The problem in client.am.Cursor can be seen if you follow the same procedure as
above, and instead of UDTTest run ParameterMappingTest with the patch for
DERBY-4891 that enables testing of booleans.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
