Re: [committed] allow assert in inner class

[Eric Blake <ebb9 at byu dot net>]

Tom Tromey wrote:

> Per> non-jls-jsr41.3-runtime-2 "Asserts do not cause class initialization"
> Per> (which is in jacks/tests/runtime/non-jls/assert/tests.tcl).
> Per> The test case does work work when compiling to native, but
> Per> fails when compiling to bytecode.  However, JDK 1.4.2 fails
> Per> in the same manner, and there is something to be said for
> Per> compatibility.
>
> I don't know about this specific case, but there are other situations
> where the JDK erroneously causes class initialization and which Sun
> has agreed are bugs.  `foo.class' is the one I know about.  I'm sure
> Eric Blake knows more.

Javac 1.4.2 only fails the test when you use the default -target 1.4.  When 
Neal Gafter at Sun added the -target 1.4.2 switch to javac, one of the changes 
it makes is that javac no longer initializes a class referenced by a class 
literal.  Likewise, jikes has not been initializing class literals for several 
releases now.  And the upcoming java 1.5 VM (now in beta), which recognizes 
ldc class_constant, does not initialize the class referenced in ldc.

At my request, Neal Gafter added Sun bug 4993813 to add 
java.lang.Class.initialize() in 1.5, so that programmers can use the idiom 
Foo.class.initialize() to express their intent to use an intialized class.

> Per> Presumably we should mark this as a Jacks XFAIL; could someone
> Per> with a Jacks account do that?
>
> Jacks xfails are handled by our test harness, see
> libjava/testsuite/libjava.jacks/jacks.xfail.  Jacks itself has no
> notion of xfail, afaik.

Correct - jacks is a pretty simplistic engine.  And figuring out how to make 
it gracefully test new 1.5 features without penalizing compilers targeting 1.4 
VMs will be interesting.  But I have jacks write privileges, and I try to stay 
on top of patches submitted to the jacks mailing list (jacks@www-124.ibm.com).

--
Someday, I might put a cute statement here.

Eric Blake             ebb9@byu.net