Question about type annotations

Tue Oct 25 01:30:39 UTC 2016

I investigated  a bit further. The issue stems from the two-phase design
currently used in javac to add type annotations (type annotations are
processed completely separately from types, which seems bad).

The  type parameters type objects are created in Attr.java,  specifically
in Attr.visitApply, which creates a list  of type attributes (with
attribAnyTypes) which is then passed to Type.ForAll and used to create the
specialized generic type.

TypeAnnotations.java then performs another pass, but crucially makes copies
of every task. It does not update the ForAll types. Is there a particular
reason for this?

Regards,
Julian

On Tue, Oct 18, 2016 at 2:34 PM Julian Bangert <bangert at google.com> wrote:

> Ok I hacked up something quick (see attachments). When running the tool, I
> get
> /usr/local/google/home/bangert/16/jdk-type-test/Annotation.java
> /usr/local/google/home/bangert/16/jdk-type-test/Testcase.java
> /usr/local/google/home/bangert/16/jdk-type-test/Generic.java
> CompilationUnit:
> /usr/local/google/home/bangert/16/jdk-type-test/Annotation.java
> CompilationUnit:
> /usr/local/google/home/bangert/16/jdk-type-test/Testcase.java
>
>
>  MethodInvocation: super()
> MethodSelect: JCTree.type: ()void
> MethodSelect: Trees.type: ()void
>
>
>  MethodInvocation: list.add(foo)
> MethodSelect: JCTree.type: (@test.Annotation java.lang.String)boolean
> MethodSelect: Trees.type: (java.lang.String)boolean
>
>
>  MethodInvocation: Generic.<@Annotation() String>Method(foo)
> MethodSelect: JCTree.type: (java.lang.String)void
> MethodSelect: Trees.type: (java.lang.String)void
> CompilationUnit:
> /usr/local/google/home/bangert/16/jdk-type-test/Generic.java
>
>
>  MethodInvocation: super()
> MethodSelect: JCTree.type: ()void
> MethodSelect: Trees.type: ()void
>
>
> The trees API always strips metadata (which is unfortunate, but other
> parts of error-prone already depend on JCType), so the annotations are
> always gone. However, when looking at the JCTree.type field, the class
> method on a generic has annotations on the substituted type parameter,
> whereas it doesn't for the generic method call. The same applies to
> constructors.
>
> Thanks again,
> Julian
> On Mon, Oct 17, 2016 at 6:00 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
> A small program that parses the test case you already provided, to get an
> AST, then walks the AST, looking for selected nodes, printing out any
> relevant info.   Essentially, encapsulate this part of your message in
> demonstrable code:
>
>
> > Now call node.getMethodSelect() on the MethodInvocation AST nodes
> > generated by this snippet. For the first call site (list.add(foo)),
> > node.getMethodSelect() returns a JCFieldAccess with type
> >
> > "(@test.Annotation java.lang.String)boolean"
> <(@test.Annotationjava.lang.String)boolean> (note the annotation).
> >
> > When I do the same for Generic.<@Annotation String>Method, I merely get
> > "(java.lang.String)void".
>
>
> If (but only if) you're familiar with the javac code base, and more
> importantly, the test base, if you know of DPrinter, you might be able to
> use that to dump the AST.  In fact, something like
>     java -classpath ...  DPrinter.Main -after PARSE -showTreeTypes
> source-files...
>
> might get you pretty much all the way to a script you could post.
>
> -- Jon
>
>
>
> On 10/17/2016 05:46 PM, Julian Bangert wrote:
>
> Thanks for the quick response -- how would you prefer the stripped down
> example? Should I send an error-prone testcase?
>
> On Mon, Oct 17, 2016 at 5:38 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
> As is typically the case in requests like this, it would help if you
> could post a working, stripped down example.
>
> You're also working with javac internal objects. It would help if you
> could post an example in terms of the public API, such as is available
> using
>      com.sun.source.*
>      javax.lang.model.*
>
> For example, if you have identified a node in an AST by a TreePath, use
>      com.sun.source.util.Trees.getTypeMirror(TreePath)
> and then, since TypeMirror extends AnnotatedConstruct, you can get the
> annotation mirrors.
>
> See:
>
> http://download.java.net/java/jdk9/docs/jdk/api/javac/tree/com/sun/source/util/Trees.html
>
> http://download.java.net/java/jdk9/docs/api/javax/lang/model/type/TypeMirror.html
>
> http://download.java.net/java/jdk9/docs/api/javax/lang/model/AnnotatedConstruct.html
>
> -- Jon
>
> On 10/17/2016 05:18 PM, Julian Bangert wrote:
> > Hello (re-sending due to moderation),
> >
> > I am working on a checker based on the error-prone framework that
> > works with (Java 8) type annotations. The javac AST seems to be
> > missing annotation types for generic methods (and constructors on
> > generic types):
> >
> > // Annotation .java
> > package test;
> > import java.lang.annotation.ElementType;
> > import java.lang.annotation.Target;
> >
> >  @Target({
> >     ElementType.TYPE_USE,
> >     ElementType.FIELD,
> >     ElementType.LOCAL_VARIABLE,
> >     ElementType.PARAMETER,
> >     ElementType.METHOD
> >   })
> > public interface @Annotation {}
> >
> >
> > // Generic.java
> >  package test;
> >   public class Generic {
> >       public static <V> void Method(V value) {
> >       }
> >   }
> >
> > // Testcase.java
> >
> > package test;
> > import java.util.List;
> > public class Testcase {
> >     void test(List<@Annotation String> list, String foo) {
> >         list.add(foo);
> >         Generic.<@Annotation String>Method(foo);
> >     }
> > }
> >
> > Now call node.getMethodSelect() on the MethodInvocation AST nodes
> > generated by this snippet. For the first call site (list.add(foo)),
> > node.getMethodSelect() returns a JCFieldAccess with type
> >
> > "(@test.Annotation java.lang.String)boolean"
> <(@test.Annotationjava.lang.String)boolean> (note the annotation).
> >
> > When I do the same for Generic.<@Annotation String>Method, I merely get
> > "(java.lang.String)void".
> >
> > Is this a bug or intended behaviour? Is there a way to get annotation
> > on the types (besides implementing my own lookup, which might be
> > buggy/unelegant).
> >
> > Regards,
> > Julian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161025/095a2baf/attachment-0001.html>