javap -c broken since b30

[Jonathan Gibbons]

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20080729/5253ecec/attachment.html