[ 
https://issues.apache.org/jira/browse/DERBY-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Knut Anders Hatlen updated DERBY-4892:
--------------------------------------

    Attachment: valueof.diff

The attached patch changes the use of the int/long constructors to calls to 
BigDecimal.valueOf(long). That method is available in Java 1.4 (and Foundation 
Profile 1.1). Its javadoc even says that it should be preferred to the int/long 
constructor (because it can reuse common values, which sounds like a good 
thing, in particular for the case in client.am.Cursor, where the value is 
always 0 or 1).

The NoSuchMethodErrors in UDTTest and ParameterMappingTest went away with the 
patch.

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

Reply via email to