• Post Reply Bookmark Topic Watch Topic
  • New Topic

Compiler bug  RSS feed

 
Geoffrey Falk
Ranch Hand
Posts: 171
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is this a bug or a feature?:





int[] and int[][] are both Object types. Since an int[][] is not an int[], it should return false.

This was tried on JDK 1.3.1, 1.4.2 and 1.5.0.

Geoffrey
 
James Carman
Ranch Hand
Posts: 580
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is a feature. The compiler knows that it can never be true, so it will throw an error.
 
scott p laplante
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To clarify by example:

class DoesntCompile {
void foo() {
Object x = new int[10][10];
boolean expectFalse = (x instanceof int[]);
}
}

DOES compile, correctly.
[ March 08, 2005: Message edited by: scott p laplante ]
 
Steve Stelting
author
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Geoffery,

At the risk of adding an "I agree" reply, James and Scott are absolutely correct. Your example is a really good illustration that Java's type checking extends to arrays as well as "standard" class types.

When the compiler evaluates a .java file, it checks that all variable assignments are type compatible throughout the file. This prevents us from assigning a reference to an incompatible object... a java.util.Date object to a java.lang.String reference, for example.

The same compiler check applies to arrays... Java recognizes that int[] is a different class type than int[][], so will generate a compiler error in your example. However, both are subclasses of Object, so we CAN assign an array to an object using a standard "widening" conversion.

Steve
 
Geoffrey Falk
Ranch Hand
Posts: 171
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to all for your enlightening replies. I guess my question pertains more to the behaviour of the "instanceof" operator. If something is definitely not an "instanceof" something else, logically it should return false instead of throwing a compiler error.

However, I appreciate the fact that the compiler tries to alert you to any possible incompatible conversions.

Geoffrey
 
Steve Stelting
author
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Geoffrey,

Yes, you raise a good point. The development team built the Java compiler to intercept and report any errors that could be detected during compile time. In the case of the instanceof operator, that means that any "impossible" tests will cause the compilation error you saw. Incidentally, we'd see the same thing if we tried to compile with an obviously incorrect class comparison. My earlier example will generate the same compiler error:




We'll only get a clean compile if the object reference could possibly be of the class type indicated on the right... and then your code would work as advertized.
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My impression is that the compiler is just doing a static type validation.

--
:alex |.::the_mindstorm::.
 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Geoffrey Falk:
Thanks to all for your enlightening replies. I guess my question pertains more to the behaviour of the "instanceof" operator. If something is definitely not an "instanceof" something else, logically it should return false instead of throwing a compiler error.

However, I appreciate the fact that the compiler tries to alert you to any possible incompatible conversions.

Geoffrey


Yet another example:


Perhaps this is overkill, but I hope it illustrates some of the problems encountered here (and the reasons for them).

Layne
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!