javap -c broken since b30
Jonathan.Gibbons at Sun.COM
Thu Jul 23 10:37:21 PDT 2009
This is now being tracked as Sun bug number 6863746
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.
>> On Tue, Jul 29, 2008 at 09:01, Jonathan Gibbons
>> <Jonathan.Gibbons at sun.com <mailto:Jonathan.Gibbons at sun.com>> wrote:
>> 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
>> 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
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev