Monkey wrench for compiling JDK 1.2 class files

["Jonathan P. Olson" <olson at mmsi dot com>]

Seems that JDK 1.2's javac has really buggered up GCJ native code compilation
for JDK 1.2.  In JDK 1.1 and earlier, Java .class files always had methods and
fields in declaration order.  This made C++ the header files generated by `gcjh'
have the same order as the original Java declarations and both C++ and Java
were happy.

Now in JDK 1.2, Sun puts out fields and methods in arbitrary hash order into
the class file.  This is OK with respect to the Java spec that states thou shalt
not assume any ordering on fields and methods.  However, it really mucks up
building native libraries, since if you compile class files with JDK 1.2, the
resulting binaries will be totally incompatible with anything built using JDK
1.1 javac or with gcj compiling directly against source.

I've had worse experiences with other byte-code compilers.  guavac can't
handle circular dependencies between Java classes and generates incorrect
code that releases monitors too soon; jikesos (from IBM) just generates plain
terrible code with dead byte code everywhere about which gcj bitterly complains.
Similarly, WIndoze tools generate generally awful byte code that often performs
illegal things like jsr`s from inside an exception region to outside an
exception region.

Seems like that the only byte code compiler that really works in combination
with `gcj' is JDK 1.1's javac.  This wouldn't be too terrible if `gcj' source
compilation had support for inner classes.  Problem is that most Java code
these days uses inner classes, and the only way to get these things compiled
is with a byte code compiler.

Oh I wish that gcj handled inner classes.  If I just had the time, that would
be my next project.....

--
Jon Olson, Modular Mining Systems
	   3289 E. Hemisphere Loop
	   Tucson, AZ 85706
olson@mmsi.com
Phone:	(520)746-9127
Fax:	(520)889-5790