Heh.
You don't get to see internal javac compiler errors every day -
this was kind of neat:
[resnick@rresnick f3]$ javac foo.java
java.lang.NullPointerException
at
sun.tools.tree.ConditionalExpression.costInline(ConditionalExpression.java)
at
sun.tools.tree.BinaryExpression.costInline(BinaryExpression.java)
at
sun.tools.tree.ExpressionStatement.costInline(ExpressionStatement.java)
at sun.tools.java.FieldDefinition.cleanup(FieldDefinition.java)
at sun.tools.java.ClassDefinition.cleanup(ClassDefinition.java)
at sun.tools.javac.Main.compile(Main.java)
at sun.tools.javac.Main.main(Main.java)
error: An exception has occurred in the compiler; please file a bug
report (http://java.sun.com/cgi-bin/bugreport.cgi).
1 error
[resnick@rresnick f3]$
I'm posting this to blackdown, rather than reporting it to Sun,
since I'm not really sure it is a Sun javac problem, and I thought
the Java/Linux folks might want to see it first.
If it turns out not to be Linux
related, my apologies in advance for bringing it up here.
I encountered this using blackdown jdk117_v1a - maybe someone can
try this on a non-linux JDK to see if it is reproducible elsewhere?
I've not tried Jikes, though I'm sure it will compile cleanly with
Jikes.
I've isolated the reproducible problem down to one snippet .java file.
The error dump above came from:
//File foo.java
public class foo
{
public void bar(Object param)
{
if (Object.class == param.getClass()) {// do something}
}
}
As you can see, the problem involves reflection in a conditional
statement.
Note that my use
of 'Object' as the type of bar's parameter is arbitrary - any type
whatsoever for 'param' will produce this problem. The problem
appears to happen when a comparison is made in a conditional if
statement
between the reflected class of a method parameter (param.getClass())
and an expected class type ( someObject.class).
Here are some other interesting variants to the above:
//Variant a - still generates the internal compiler error
public class foo
{
public void bar(Object param)
{
// flip around the order of the == comparison arguments
if (param.getClass() == Object.class) {}
}
}
//Variant b - still generates the internal compiler error
public class foo
{
public void bar(Object param)
{
// try a different comparison operator -- !=
if (param.getClass() != Object.class) {}
}
}
//Variant c - compiles cleanly!
public class foo
{
public void bar(Object p)
{
Object param = p;
// replace the method parameter with an on-stack variable:
if (param.getClass() != Object.class) {}
}
}
Anyone else ever encountered this sort of thing?
Regards,
Ron.
---
Ron Resnick
Senior Consulting Engineer
DiaLogos Incorporated
http://www.dialogosweb.com
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
