[abc] on test 667 and adaptj-pooling-FFT

These tests fail with abc crashing because it doesn't know what to do
with a class generated by j2j that was not present in the original
source.

The class is needed to implement .class literals (which are used by the
assert implementation, or by user code). .class literals are implemented
by some code that calls Class.forName().

Javac and Jikes both put this code in the class whose literal we are
asking for. When that class is an interface, they can't put code into
it, so they generate this helper class instead.

Eclipse and Ajc, instead, inline the code that would go
in this method into all call sites of the method. I don't believe that
this is legal, since in the presence of user-defined class loaders, it
may get the wrong class from the wrong class loader, but I could be
wrong. Still, I imagine that Javac and Jikes have a good reason for the
additional complexity of introducing a new class.

JSR-202 changes the .class file format to add direct support for .class
literals, making this extra code and the generated class unnecessary.
This JSR was intended to be included in Java 1.5, but I haven't been
able to confirm whether it has been included.

The question is, should this generated class be weavable,
declare-parents-able, etc. In ajc, it clearly isn't (when compiling from
source), since it's not generated in the first place. Once JSR-202 is
approved, it will not be generated even in Javac. I think abc should
just pretend it doesn't exist.

Ondrej
Received on Mon Sep 13 18:06:49 2004