You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Ray Kiddy <ki...@apple.com> on 2006/07/13 18:38:32 UTC
BigDecimal incompatibility from 1.5 -> 1.4
I have been e-mailing with Andrew McIntyre about getting some things
done in the build of Derby on Mac OS X.
We (at Apple) are seeing something and I am wondering how you all
have dealt with this issue. At one time, we thought we could use Java
1.5 and achieve backwards compatibility with 1.4. We have seen an
issue with BigDecimal and I wonder if this has impacted you all, or
how you have dealt with it.
The problem is this. If one used a method in 1.4, java.math.BigDecimal
(int), the javac compiler would map this for you, under the covers,
to java.math.BigDecimal(double).
If one builds in 1.5 with no options, one gets the new API included
in 1.5. So, java.math.BigDecimal(int) works as is and there is no
reason for javac to do any magic underneath the covers.
But, if one builds "javac -source 1.4 -target 1.4", then one gets the
classes in the right class file format for running in the 1.4 VM, but
the javac compiler has not done the mapping. Result? A runtime
exception. The 1.4 VM does not know the method java.math.BigDecimal
(int).
The code below demonstrates this concretely.
Just curious how you all are dealing with this, or if you have had to.
thanx - ray
%
% echo "public class foo { public static void main(String[] arg)
{ java.math.BigDecimal d = new java.math.BigDecimal(10);
System.out.println(d); } }" > foo.java
%
% java -version
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)
Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing)
%
%
% javac -classpath . foo.java
%
% javap -c -classpath . foo
Compiled from "foo.java"
public class foo extends java.lang.Object{
public foo();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: new #2; //class java/math/BigDecimal
3: dup
4: bipush 10
6: invokespecial #3; //Method java/math/BigDecimal."<init>":(I)V
9: astore_1
10: getstatic #4; //Field java/lang/System.out:Ljava/io/
PrintStream;
13: aload_1
14: invokevirtual #5; //Method java/io/PrintStream.println:
(Ljava/lang/Object;)V
17: return
}
%
% /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Commands/
javac -bootclasspath /Users/ray/Library/Java:/Library/Java:/System/
Library/Java:/Network/Library/Java:/System/Library/Frameworks/
JavaVM.framework/Versions/1.4.2/Classes/classes.jar:/System/Library/
Frameworks/JavaVM.framework/Versions/1.4.2/Classes/ui.jar -extdirs /
System/Library/Java/Extensions -classpath . foo.java
%
%
% /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Commands/
javap -bootclasspath /Users/ray/Library/Java:/Library/Java:/System/
Library/Java:/Network/Library/Java:/System/Library/Frameworks/
JavaVM.framework/Versions/1.4.2/Classes/classes.jar:/System/Library/
Frameworks/JavaVM.framework/Versions/1.4.2/Classes/ui.jar -extdirs /
System/Library/Java/Extensions -classpath . -c foo
Compiled from "foo.java"
public class foo extends java.lang.Object{
public foo();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: new #2; //class BigDecimal
3: dup
4: ldc2_w #3; //double 10.0d
7: invokespecial #5; //Method java/math/BigDecimal."<init>":(D)V
10: astore_1
11: getstatic #6; //Field java/lang/System.out:Ljava/io/
PrintStream;
14: aload_1
15: invokevirtual #7; //Method java/io/PrintStream.println:
(Ljava/lang/Object;)V
18: return
}
%
% javac -source 1.4 -target 1.4 foo.java
%
% javap -c -classpath . foo
Compiled from "foo.java"
public class foo extends java.lang.Object{
public foo();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: new #2; //class java/math/BigDecimal
3: dup
4: bipush 10
6: invokespecial #3; //Method java/math/BigDecimal."<init>":(I)V
9: astore_1
10: getstatic #4; //Field java/lang/System.out:Ljava/io/
PrintStream;
13: aload_1
14: invokevirtual #5; //Method java/io/PrintStream.println:
(Ljava/lang/Object;)V
17: return
}
%
- ray
Re: BigDecimal incompatibility from 1.5 -> 1.4
Posted by Daniel John Debrunner <dj...@apache.org>.
Ray Kiddy wrote:
>
> I have been e-mailing with Andrew McIntyre about getting some things
> done in the build of Derby on Mac OS X.
>
> We (at Apple) are seeing something and I am wondering how you all have
> dealt with this issue. At one time, we thought we could use Java 1.5
> and achieve backwards compatibility with 1.4. We have seen an issue
> with BigDecimal and I wonder if this has impacted you all, or how you
> have dealt with it.
>
> The problem is this. If one used a method in 1.4, java.math.BigDecimal
> (int), the javac compiler would map this for you, under the covers, to
> java.math.BigDecimal(double).
> Just curious how you all are dealing with this, or if you have had to.
The Derby code only (hopefully) uses that method when passing a double
to it. The automatic promotion of a long or an int to a double caused
problems for the SQL type system, where a precise type such as BIGINT
would be incorrectly converted to an imprecise value through this
method. This would occur when casting a BIGINT to a DECIMAL or the
application fetching a BIGINT as a java.math.BigDecimal.
If you've found any instances of this call in Derby code, could you
enter a Jira issue to fix them to use the BigDecimal.valueOf() call.
Dan.
Re: BigDecimal incompatibility from 1.5 -> 1.4
Posted by Ray Kiddy <ki...@apple.com>.
On Jul 13, 2006, at 11:25 AM, Ray Kiddy wrote:
>
> On Jul 13, 2006, at 11:01 AM, Craig L Russell wrote:
>
>> Hi Ray,
>>
>> This sounds like a bug in the compiler. Have you raised an issue
>> with the JDK folks?
>>
>> Craig
>>
>
> It had not occurred to me to look at this as a bug in the 1.5
> javac. I think I will file that with Sun. I was just thinking that
> the 1.4.2 compiler was, you know, done.
>
> - ray
>
FYI, it appears that if you use the 1.5 javac AND specify the 1.4
libraries, the compiler does the right thing. In talking to other
people, I have been convinced that Sun would say this is correct
behavior.
To get true 1.4 compatibility, you need "-source 1.4 -target 1.4" and
you need to reference the correct -bootclasspath and -extdirs.
- ray
% /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/
javac -bootclasspath /Users/ray/Library/Java:/Library/Java:/System/
Library/Java:/Network/Library/Java:/System/Library/Frameworks/
JavaVM.framework/Versions/1.4.2/Classes/classes.jar:/System/Library/
Frameworks/JavaVM.framework/Versions/1.4.2/Classes/ui.jar -extdirs /
System/Library/Java/Extensions -classpath . -source 1.4 -target 1.4
foo.java
%
% java -version
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)
Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing)
%
%
% /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/
javap -bootclasspath /Users/ray/Library/Java:/Library/Java:/System/
Library/Java:/Network/Library/Java:/System/Library/Frameworks/
JavaVM.framework/Versions/1.4.2/Classes/classes.jar:/System/Library/
Frameworks/JavaVM.framework/Versions/1.4.2/Classes/ui.jar -extdirs /
System/Library/Java/Extensions -classpath . -c foo
Compiled from "foo.java"
public class foo extends java.lang.Object{
public foo();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: new #2; //class java/math/BigDecimal
3: dup
4: ldc2_w #3; //double 10.0d
7: invokespecial #5; //Method java/math/BigDecimal."<init>":(D)V
10: astore_1
11: getstatic #6; //Field java/lang/System.out:Ljava/io/
PrintStream;
14: aload_1
15: invokevirtual #7; //Method java/io/PrintStream.println:
(Ljava/lang/Object;)V
18: return
}
%
Re: BigDecimal incompatibility from 1.5 -> 1.4
Posted by Ray Kiddy <ki...@apple.com>.
On Jul 13, 2006, at 11:01 AM, Craig L Russell wrote:
> Hi Ray,
>
> This sounds like a bug in the compiler. Have you raised an issue
> with the JDK folks?
>
> Craig
>
It had not occurred to me to look at this as a bug in the 1.5 javac.
I think I will file that with Sun. I was just thinking that the 1.4.2
compiler was, you know, done.
- ray
> On Jul 13, 2006, at 9:38 AM, Ray Kiddy wrote:
>
>>
>> I have been e-mailing with Andrew McIntyre about getting some
>> things done in the build of Derby on Mac OS X.
>>
>> We (at Apple) are seeing something and I am wondering how you all
>> have dealt with this issue. At one time, we thought we could use
>> Java 1.5 and achieve backwards compatibility with 1.4. We have
>> seen an issue with BigDecimal and I wonder if this has impacted
>> you all, or how you have dealt with it.
>>
>> The problem is this. If one used a method in 1.4,
>> java.math.BigDecimal(int), the javac compiler would map this for
>> you, under the covers, to java.math.BigDecimal(double).
>>
<snip>
Re: BigDecimal incompatibility from 1.5 -> 1.4
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Ray,
This sounds like a bug in the compiler. Have you raised an issue with
the JDK folks?
Craig
On Jul 13, 2006, at 9:38 AM, Ray Kiddy wrote:
>
> I have been e-mailing with Andrew McIntyre about getting some
> things done in the build of Derby on Mac OS X.
>
> We (at Apple) are seeing something and I am wondering how you all
> have dealt with this issue. At one time, we thought we could use
> Java 1.5 and achieve backwards compatibility with 1.4. We have seen
> an issue with BigDecimal and I wonder if this has impacted you all,
> or how you have dealt with it.
>
> The problem is this. If one used a method in 1.4,
> java.math.BigDecimal(int), the javac compiler would map this for
> you, under the covers, to java.math.BigDecimal(double).
>
> If one builds in 1.5 with no options, one gets the new API included
> in 1.5. So, java.math.BigDecimal(int) works as is and there is no
> reason for javac to do any magic underneath the covers.
>
> But, if one builds "javac -source 1.4 -target 1.4", then one gets
> the classes in the right class file format for running in the 1.4
> VM, but the javac compiler has not done the mapping. Result? A
> runtime exception. The 1.4 VM does not know the method
> java.math.BigDecimal(int).
>
> The code below demonstrates this concretely.
>
> Just curious how you all are dealing with this, or if you have had to.
>
> thanx - ray
>
>
> %
> % echo "public class foo { public static void main(String[] arg)
> { java.math.BigDecimal d = new java.math.BigDecimal(10);
> System.out.println(d); } }" > foo.java
> %
> % java -version
> java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-112)
> Java HotSpot(TM) Client VM (build 1.5.0_06-64, mixed mode, sharing)
> %
> %
> % javac -classpath . foo.java
> %
> % javap -c -classpath . foo
> Compiled from "foo.java"
> public class foo extends java.lang.Object{
> public foo();
> Code:
> 0: aload_0
> 1: invokespecial #1; //Method java/lang/Object."<init>":()V
> 4: return
>
> public static void main(java.lang.String[]);
> Code:
> 0: new #2; //class java/math/BigDecimal
> 3: dup
> 4: bipush 10
> 6: invokespecial #3; //Method java/math/BigDecimal."<init>":
> (I)V
> 9: astore_1
> 10: getstatic #4; //Field java/lang/System.out:Ljava/io/
> PrintStream;
> 13: aload_1
> 14: invokevirtual #5; //Method java/io/PrintStream.println:
> (Ljava/lang/Object;)V
> 17: return
>
> }
>
> %
> % /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/
> Commands/javac -bootclasspath /Users/ray/Library/Java:/Library/
> Java:/System/Library/Java:/Network/Library/Java:/System/Library/
> Frameworks/JavaVM.framework/Versions/1.4.2/Classes/classes.jar:/
> System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Classes/
> ui.jar -extdirs /System/Library/Java/Extensions -classpath . foo.java
> %
> %
> % /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/
> Commands/javap -bootclasspath /Users/ray/Library/Java:/Library/
> Java:/System/Library/Java:/Network/Library/Java:/System/Library/
> Frameworks/JavaVM.framework/Versions/1.4.2/Classes/classes.jar:/
> System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Classes/
> ui.jar -extdirs /System/Library/Java/Extensions -classpath . -c foo
> Compiled from "foo.java"
> public class foo extends java.lang.Object{
> public foo();
> Code:
> 0: aload_0
> 1: invokespecial #1; //Method java/lang/Object."<init>":()V
> 4: return
>
> public static void main(java.lang.String[]);
> Code:
> 0: new #2; //class BigDecimal
> 3: dup
> 4: ldc2_w #3; //double 10.0d
> 7: invokespecial #5; //Method java/math/BigDecimal."<init>":
> (D)V
> 10: astore_1
> 11: getstatic #6; //Field java/lang/System.out:Ljava/io/
> PrintStream;
> 14: aload_1
> 15: invokevirtual #7; //Method java/io/PrintStream.println:
> (Ljava/lang/Object;)V
> 18: return
>
> }
>
> %
> % javac -source 1.4 -target 1.4 foo.java
> %
> % javap -c -classpath . foo
> Compiled from "foo.java"
> public class foo extends java.lang.Object{
> public foo();
> Code:
> 0: aload_0
> 1: invokespecial #1; //Method java/lang/Object."<init>":()V
> 4: return
>
> public static void main(java.lang.String[]);
> Code:
> 0: new #2; //class java/math/BigDecimal
> 3: dup
> 4: bipush 10
> 6: invokespecial #3; //Method java/math/BigDecimal."<init>":
> (I)V
> 9: astore_1
> 10: getstatic #4; //Field java/lang/System.out:Ljava/io/
> PrintStream;
> 13: aload_1
> 14: invokevirtual #5; //Method java/io/PrintStream.println:
> (Ljava/lang/Object;)V
> 17: return
>
> }
>
> %
>
> - ray
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!