javap -c broken since b30

[Jonathan Gibbons]

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 
> > 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/20090714/5536068f/attachment.html