Implementation of changed bytecode representation
wdietl at gmail.com
Mon Dec 10 04:45:01 PST 2012
I pushed my first version of the new bytecode representation.
This is my interpretation of what the consensus from the different
"spec" lists was. Once we have a final spec, I can double check
I currently have 5 tests failing, all related to the changed numbering
of inner types. I need to think this through some more and hopefully
can clean up a few more things.
I also did the "@A java.lang.Object" to "java.lang. at A Object" change,
which made the AST nicer, because we no longer need the onRightType
I renamed the constants and updated the tests in
to the new location format. It's a pain to write these byte arrays by
hand, but I didn't see a quick way to update the testing
Please have a look at the tests and the code and let me know whether
you see any problems.
I will next:
- fix inner type numbering
- fix JavaDoc/Symbol issue
- look at exception and lambda storage (I added constants and some
groundwork; for lambda i really need a spec to know what has to be
- the few small other things from previous mail
On Wed, Dec 5, 2012 at 6:03 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
> On 12/03/2012 01:15 AM, Werner Dietl wrote:
>> Please find a patch against the type-annotations/langtools repository
>> attached (I just pushed a recent merge with tl).
>> I implemented many of the recently discussed bytecode changes: reorder
>> elements, remove _COMPONENT TargetTypes, and introduce TypePathEntry.
>> It's not quite done yet: I still need to separate numbering of type
>> arguments and arrays/inner types, renumber inner types, and adapt the
>> referenceinfo test cases (which will be a big pain and I would prefer
>> doing this only once).
>> I would appreciate feedback on the changes to class
>> com.sun.tools.javac.code.TypeAnnotationPosition, in particular how I
>> added TypePathEntry, TPEKind, and the new location field.
>> The whole com.sun.tools.javac package hierarchy compiles; packages
>> classfile and javap currently won't compile, as they depend on code
>> duplicated from TypeAnnotationPosition and I only want to copy that
>> code over once. The uses are however mostly adapted already.
>> All comments very welcome!
>> cu, WMD.
> Generally, code looks good, except for the //TODO's.
> -- Jon
More information about the type-annotations-dev