[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-type-annotations-dev
Subject:    Type Annotations: The next steps
From:       Eric McCorkle <eric.mccorkle () oracle ! com>
Date:       2014-06-12 12:05:57
Message-ID: 539997A5.3020900 () oracle ! com
[Download RAW message or body]


The first major wave of type annotations refactorings is now checked in
to the jdk9-dev repositories.  The javac compiler group is currently
evaluating the pros and cons of including this work in the 8u20 update
release (if anyone has information relevant to this decision process,
please let me know).


The objectives of the first wave of type annotations work were as follows:
* Integrate the type annotation frontend logic with the javac pipelines
* Clean up and modularize the code
* Ensure that an Attribute.Compound has the correct type annotation
position (with respect to position type, type path, and some of the
offsets) from the moment it is created, and that it does not change
after that.
* Permit a single source annotation to generate multiple bytecode
annotations.
* Unify the codepaths for handling declaration annotations and type
annotations
* Get rid of AnnotatedType


As of last Friday, these have been accomplished; however, we are far
from finished.  I am currently planning another wave of work (which
should be smaller in scope).  Here is a brief overview of the objectives:

1) Every Type should be guaranteed to have the correct annotations, in
the same way that every Attribute.Compound is now guaranteed to have the
correct type annotation position.  Specifically, after Attr it should be
possible to read off the type annotations on any particular Type with
getAnnotationMirrors() (for Type's on a declaration, this should be
possible after MemberEnter).  Another part of this work is making sure
that the functions on Type's (erasure, superType, etc.) behave as they
ought to.

2) Investigate options for cleaning up some of the backend code (in Gen)
that are enabled by the ability to read annotations directly off the
Type.  I looked into a more direct implementation of some of the logic
in Gen.  As I recall, the problem was that Lower had stripped out the
AnnotatedType's, effectively erasing annotations.  It would be nice if
the logic in Gen could operate directly on the tree and its Type, as
opposed to the roundabout method of comparing source positions to figure
out if it should set the bytecode index for a type annotation.

3) Cleanup of the existing code.  We still aren't where I want to be in
terms of code cleanliness in the frontend pipeline.  I think the
frontend pipeline is in much better shape overall, but it still has a
very "construction site" feel to it.  We need to spend some time
polishing it up and tightening down the bolts, so to speak.

4) The javac compiler group is currently discussing doing some extensive
work on the general annotations pipeline.  There are several aspects of
the existing system that have become a liability, and we are considering
ways to rework the pipeline to eliminate those difficulties.

5) Currently, the enforcement of semantic rules is rather disorganized
and ad-hoc.  I would like it to be more centralized and maintainable,
though I don't have a clear roadmap for accomplishing that at this time.

["eric_mccorkle.vcf" (text/x-vcard)]

[prev in list] [next in list] [prev in thread] [next in thread]