A tool that's based on reflection seems pretty useless as a javap
replacement. (It's useful for a lot of the things javap is
used for, such as reverse engineering etc.) As a debugging tool,
however, javap's purpose is to examine the actual content of a .class
file, not necessarily the result of what was in a well-formed class file
that passes the class loading process.
- Godmar
>
> > From: Wes Biggs [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 30, 1998 11:40 AM
> >
> > > 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.
> >
>
> He's right, if you're running under Sun's JDK it's pretty much useless.
> However, there is a way: Create a ClassLoader that works off of Classpath's
> classes. Maybe use the JarClassLoader.
