There is another modification to your code the makes the compiler happy:
public class foo {
static Class oClass = (new Object()).getClass();
public void bar(Object param) {
if (oClass == param.getClass()) {
/* do nothing */ ;
}
}
}
Why is that?
I don't know - I can only try to bring some light to how javac is translating
your code and point to a very related bug.
The expression Object.class generates code that you certainly don't expect.
javac has a very broken way of handling expressions containing .class.
Basically when used in a class A the .class expressions are replaced by
references to implicitly generated static members of type Class. When the same
.class expression is encountered in class B, derived from class A the compiler
relies on the static member of A. Only was this static member of A implicitly
declared private. Therefore you should get a security exception during runtime
when B tries to evaluate your .class expression and that is what you get on
none Sun derived VMs.
So maybe in the original "/* do nothing */" version of the example the implicit
static member is optimized away. This would cause the first operator to be
missing from the '==' expression in the if statement. This could easily cause:
java.lang.NullPointerException
at
sun.tools.tree.ConditionalExpression.costInline(ConditionalExpression.java)
Look at this code again:
public class foo {
public void bar(Object param) {
if (Object.class == param.getClass()) {
new Integer(0);
}
}
}
javac it. Decompile the class file (with JAD for example) and this is what you
get:
public class foo
{
public void bar(Object obj)
{
if((class$java$lang$Object == null ? (class$java$lang$Object =
class$("java.lang.Object")) : class$java$lang$Object) == obj.getClass())
new Integer(0);
}
public foo()
{
}
static Class class$(String s)
{
try
{
return Class.forName(s);
}
catch(ClassNotFoundException classnotfoundexception)
{
throw new
NoClassDefFoundError(classnotfoundexception.getMessage());
}
}
static Class class$java$lang$Object; /* synthetic field */
}
Ron Resnick wrote:
> Thanks for the rapid responses Martin, Steve. I'll quickly take this
> off blackdown due to its non-Linux relevance. I thought I would point
> out the following though:
>
> If you insert an actual executable hunk of code into the if block,
> things work properly. Eg, consider
>
> class foo
> {
> void bar (Object o)
> {
> if (o.getClass() == Object.class)
> {
> Integer p // = new Integer(5)
> ;
> }
> }
> }
>
> As written, this generates the internal compiler error, since the simple
> allocation
> of reference p doesn't require runtime execution. However, uncomment the
> initializer ( = new Integer(5)), and the internal compiler error
> disappears.
> The act of invoking new() seems to force the compiler to follow a
> clean path, as opposed to a dirty one.
>
> Looking at this, my guess is that the problem is caused by some
> optimization
> dealing with parameters on the stack. When the optimization is forcibly
> turned
> off, the problem goes away.
>
> OK, I'll stop annoying you all. I guess I was just intrigued think about
> what kind of internal optimization path could possibly account for these
> unlikely stimuli turning on or off the behaviour.
>
> Ron
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
S/MIME Cryptographic Signature
