[
https://issues.apache.org/jira/browse/DERBY-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen closed DERBY-4892.
-------------------------------------
Resolution: Fixed
Fix Version/s: 10.7.1.0
Committed revision 1032481.
> 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
> Fix For: 10.7.1.0
>
> Attachments: valueof.diff
>
>
> 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.
