Well, I have been compiling things with guavac now, and came up with about
six specific things javac can handle and guavac cannot. Here are the ones I
remember:
1. Inner classes cannot have the private modifier. Workaround: just make
it package-private instead.
2. In an inner class, cannot refer to the enclosing class's instance using
"<classname>.this". You can refer to the methods and fields in the
enclosing class without
3. Cannot refer to classes explicitly in the source, i.e.
gnu.java.lang.ClassHelper.getSignature(). Actually it may only be that you
cannot do this when you use the method or field on the right side of an
operator (+ and = are the specific ones I have run into so far). Workaround
is simply to import that class at the top and refer to it directly.
4. Cannot use <classname>.class.<method in Class class>(). Plain old
<classname>.class works fine and can be assigned to a variable of type
Class. That is the workaround, incidentally. Assign it to a class variable
and use the methods in that Object. I don't like this workaround; it seems
to me that it is not as speedy as it could be.
5. Can't handle .jar files in the classpath. Workaround is to rename it as
.zip.
#2 is the only one that sometimes requires extensive changes to work
around. If the inner class wants to call clear() in the enclosing class,
but the inner class has defined clear() already, there is no direct way to
do it. I am working around it by calling a method of a different name, like
enclosingClear() in the enclosing class which calls the method I really want
(clear()).
I'm just going through and manually fixing what I can; but I am having to
do some kludges to make sure things still work. It'll be a tedious process.
Guavac is our only option, however, given that Sun doesn't properly compile
some core classes (like Object, Class, and Thread).
The method I am using to compile everything is thus:
I use guavac with classpath of <outputted classes directory>:<JDK 1.2b4
rt.jar renamed to .zip>:<source directory>. The filenames to compile are in
a file called 'sources'. I got the list of filenames by doing find
java -name \*.java and find gnu -name \*.java in Classpath root. Whenever I
find a class that depends on something that hasn't been compiled yet, I
simply move the classname up in the sources file and redo the whole thing.
Crude, but effective for my purposes. Things are going OK so far.
The only time-consuming thing is changing the files to work with guavac. I
will not check in most of that work because it is guavac that should be
fixed, not Classpath. Some of the workarounds are dead ugly (esp. #2 and
#4), but if a file only runs into bug #3, I'll check it in.
--John Keiser
