javap -c broken since b30

[Jonathan Gibbons]

This is now being tracked as Sun bug number 6863746

-- Jon

Jonathan Gibbons wrote:
> Yes. I agree. This is on the list and will be fixed "soon", probably M5.
>
> -- Jon
>
>
> On Jul 13, 2009, at 11:49 AM, Martin Buchholz wrote:
>
>> A followup:
>>
>> Currently one still needs to supply -XDignore.symbol.file
>> to be able to use javap with jdk internal classes.
>> Even for me it's hard to remember this,
>> and it will be impossible for others to figure this out.
>>
>> I think we will need to do something to make javap
>> "just work" before jdk7 ships, or this will be a fruitful
>> source of bug reports, since it appears to be an
>> "obvious" regression.
>>
>> Martin
>>
>> On Tue, Jul 29, 2008 at 09:01, Jonathan Gibbons 
>> <Jonathan.Gibbons at sun.com <mailto: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
>>>
>>
>>
>

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