Skip to main content

How do I report a Compiler Bug?

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
3 replies [Last post]
iancurrie
Offline
Joined: 2011-02-06

I have come across a compiler error. I have no no idea whether this bug has been reported before - the error reporting system (Bugzilla?) seems quite impenetrable.
I am using NetBeans 6.9.1with Java 1.6.0_21, running on Windows XP version 5.1.
The following program illustrates the bug. The methods dup1 and dup2 should be semantically equivalent with the numbers involved and the method dup should print nothing.
static int dup1(Integer a, Integer b){
int ans = 0;
if (a>b){ans=ans+2;}
else if(a==b) ans=ans + 1;
return ans;
}
static int dup2(Integer a, Integer b){
int ans = 0;
if (a>b){ans=ans+2;}
else if(a-b==0) ans=ans + 1;
return ans;
}
static void dup(Integer a, Integer b){
int a1 = dup1(a,b);
int a2 = dup2(a,b);
if (a1!=a2){
System.out.println("dup1("+a+","+b+")="+a1);
System.out.println("dup2("+a+","+b+")="+a2);
}
}

public static void main(String[]args){
for(int i = 0; i<130; i=i+1){
dup(i,i); dup(-i,-i);
}
}
This gives the output:
dup1(128,128)=0
dup2(128,128)=1
dup1(129,129)=0
dup2(129,129)=1
dup1(-129,-129)=0
dup2(-129,-129)=1
Note that the two methods give the same answer for numbers between -128 and 127. I suspect that there is a fallacious optimisation on the equality test making use of the use of the result of the previous greater-than test.
I hope that somebody knows how to report this bug properly.
Ian Currie

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cowwoc
Offline
Joined: 2003-08-24

Hi iancurrie,
This isn't a compiler bug. This is a consequence of the AutoBoxing feature introduced in Java 5: http://download.oracle.com/javase/1.5.0/docs/guide/language/autoboxing.html
Int values between the range of -128 to 127 are converted to the same Integer instances (which is why object-equality is returning true) whereas ints outside this range return different Integer instances (which is why == returns false).
To fix this, replace a==b with a.equals(b) in the dup1 method.
Kind Regards,
Gili

iancurrie
Offline
Joined: 2011-02-06

Hi Gili
Thanks for pointing out a monstrous property of the Java definition. I confirmed it by simplifying my example.
I was quite aware that Integers are represented by pointers but to define equality between Integers as the equality of the pointers is bizzare in the extreme - the bug is not in the compiler but in the definition of Java itself - which I find hard to take . It means that , besides flying in the face of normal mathematical usage, the equality is mutually inconsistent with other operations in Java - (a==b) would be different from (a+0 ==b) , (-a == -b) besides my example of ((a-b)==0).
Your reference to "autoboxing" seems to indicate that this decision was taken a good deal down the line in language development ; I wonder what other silly decisions have been made. The correct decision would have been either to forbid entirely the use of == between Integers or else implement it correctly and use another operation for identity of instances. It would certainly saved me a lot of debugging time.
Ian

iancurrie
Offline
Joined: 2011-02-06

Hi Gili
I hope are still listening to this thread - no one else is, apparently!
Since my last diatribe, the full consequences of the idiotic definition of equality between Integers has gradually dawned on me. Consider the following scenario:
Suppose that Java was used to implement a GUI interface for a neuclear station control program (Heaven forbid!). The originator of the program has made the same "mistake " as I made (that == means numerial equality when applied to Integers). As it happens all the Integer values that were used were state values that could equally have been expressed as bytes. As a result, all the testing and validation exercises passed with flying colours - as it had to in a safety-critical situation like this.
The program runs faultlessly for several years until an upgrade was made on the reactor. The program had to modified by adding a few more state values. Once again the validation tests gave the green light, and indeed the program worked normally for for a few more months until state 128 was triggered - or rather not triggered since it was not recognised. This is unfortunate since it is required for an emergency shut down - the core then melts down all the way through to China, as they said in the film.
If you think this is fanciful, replace the "nuclear reactor" by "Ariane rocket" , "state value" by "angle of attack" (i can't remember the unit, but it was expressed as a byte), "upgrade" was "Ariane3" to "Ariane4" and perhaps you can understand Ariane4's maiden flight landed in the Atlantic, when the attitude controls received an overflow exception message (in clear text on stderr). None of the quality control on the modified programs took account of the increase of range of this byte value required for increased power of the new rocket.
Ian