Wes Biggs wrote:
>
> > 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.
Wouldn't it be possible to simply use a custom ClassLoader? At least in
1.2, there is a URLClassLoader which would seem to fit our needs - and
1.2 has a Class.forName(String, ClassLoader) (or something like that) to
make it easy. I don't know the exact mechanism to load a class with a
custom ClassLoader under 1.1, but I know it can be done.
HTH,
Stuart.
