javap -c broken since b30

[Jonathan Gibbons]

The fact that javap happens to live in tools.jar is irrelevant; other  
than a home
for javap, tools.jar does not come into the classpath here.

-- Jon


On Jul 29, 2008, at 8:29 PM, Martin Buchholz wrote:

> Interesting.
>
> I had expected javap to use the same bootclasspath as java,
> not the same as the compile time environment created by javac.
> Ahhh, but perhaps javap is implemented via tools.jar?
> Then javap's launcher should add tools.jar to the bootclasspath
> for javap's benefit, but should search for class files by default
> via a different bootclasspath, one not containing tools.jar or ct.sym.
>
> javap is not javac!
>
> Martin
>
> On Tue, Jul 29, 2008 at 9:01 AM, Jonathan Gibbons
> <Jonathan.Gibbons at sun.com> wrote:
>> Martin,
>>
>> I agree with your report. javap isn't really behaving in
>> this case as expected, but it's not entirely wrong either.
>>
>> There is indeed a new version of javap (complete rewrite)
>> from b30. It handles all the latest attributes and annotations,
>> etc. It fixes the majority of all outstanding javap bugs. It will
>> also be significantly more maintainable going forward.
>> It also uses the same mechanisms as javac to find classes
>> -- there were a number of bugs against the javap classpath
>> code.    And here is where the problem arises.   In the
>> example you give, it is finding java.lang.String in ct.sym,
>> and the version there does not have any Code attributes
>> to dump.
>>
>> Like javac, you can give -XDignore.symbol.file to ignore ct.sym,
>> and then I think you will find that the -c option behaves as
>> expected.
>>
>> There is a new option coming up called -sysinfo. [It's currently
>> stuck in CCC :-(]  With that option, you will be able to get "system"
>> info about classes being dumped. This will include the path, size,
>> last modified time, and an MD5 hash.
>>
>> In this case, it will give output like:
>>
>> $ dist/bin/javap -sysinfo java.lang.String
>> Classfile
>> jar:/usr/lib/jvm/java-6-sun-1.6.0.03/lib/ct.sym!java/lang/ 
>> String.class
>> Last modified Sep 24, 2007; size 3629 bytes
>> MD5 checksum 61b898f91e92a4ec4980ec7e93a3662b
>> Compiled from "String.java"
>>    // etc
>>
>> -- Jon
>>
>>
>>
>> Jonathan Gibbons wrote:
>>
>> A formal bug report would also get my attention, but this will do  
>> too.
>> Consider my attention gotten.
>>
>> -- Jon
>>
>> On Jul 29, 2008, at 7:07 AM, Martin Buchholz wrote:
>>
>> (I hope this is the right mailing list to report javap bugs)
>>
>> Since jdk7-b30, a command line like
>>
>> javap -c java.lang.String
>>
>> no longer prints the disassembled bytecode of methods.
>> Which would seem to be a P1 bug, at least for those of
>> us who like to pore over javap output, trying to squeeze
>> a bytecode here or there.
>>
>> Using linux-i586.
>>
>> Martin
>>
>>
>>