> Okay, one other thing which seems crucial to me. How can I use this
> in such a way as to have the tool look at Classpath's java.lang.String
> and not Sun's java.lang.String? There is no classpath option in the
> usage section. I'm not sure if ordering of the items in the CLASSPATH
> env. variable is sufficient.
ClassTool uses reflection, so it has to rely on the VM mechanism for loading
classes (via Class.forName(String)). If ordering things in CLASSPATH (or
perhaps the variations introduced in 1.2, -sysclasspath...) doesn't work, it
may not be useful for that. We'd have to write a bytecode decompiler, which
is what I was trying to avoid in the first place.
Wes
P.S. fixed the --compatibility flag, silly error.
http://www.cacas.org/java/gnu/tools/ClassTool.java
