>> > 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.
I think, "bytecode parser" based on reflection is not very useful.
By many reasons. For example, when I saw the code of reflection
package - there were a lot of method that simply returns null
with /* not yet implemented*/ comment.
Also, there are a lot of java bytecode file parsers. In any java compiler
at least, plus much more. Since, this tools does not need to be
clean-room, I can write you one in a day or two. Just say me what
you need exactly ;-)
