interactions between type annotations and language model APIs.

Joe Darcy joe.darcy at
Sun May 11 16:23:58 UTC 2014

Hi Bruce,
On 5/11/2014 1:35 AM, Bruce Chapman wrote:
> I think you are on the right track here. Types' methods would probably 
> strip type annotations, but provide tools for the user to reinsert 
> them when the user knows that is appropriate and valuable given the 
> semantics of the annotation and what the code is trying to do.  I am 
> presuming Joe's second method would in some way back substitute an 
> annotated type for an (possibly) unannotated type within the 
> typeMirror argument?

The intention is the second method was that the returned value would be 
a wrapper around the first argument that had the annotations of the 
second argument.

> withAnnotations(typeof(List<String>), typeof(@Nullable String)> would 
> return typeof(List<@Nullable String>?

I intended this to return

@Nullable List<String>

> if so, what happens when the second argument appears more than once in 
> the first argument? e.g. Map<String, List<String>?
> Despite these difficulties, I still think stripping then tools to 
> reinsert the type annotations is what would be most useful.
> The alternative would be some way to tell types' method what should 
> happen.

I don't see you good way to approach that problem. Stripping the 
annotations and allowing them to be added, gives interested parties full 
control while being a tractable API.



> Bruce
> On 10/05/2014 9:36 a.m., Alex Buckley wrote:
>> Joe,
>> On 5/9/2014 8:24 AM, Joe Darcy wrote:
>>> My first reaction here is that these methods should by default ignore
>>> annotations and we should add another utility method or two like:
>>> <T extends TypeMirror> T withAnnotations(T typeMirror, List<? extends
>>> AnnotationMirror> annotations)
>>> <T extends TypeMirror> T withAnnotations(T typeMirror,
>>> AnnotatedConstruct annotationHost)
>>> to allow the annotations savvy user to perform whatever annotation
>>> passing along or computation is appropriate for the problem domain.
>> In other words, specify in javax.lang.model.util.Types that it is 
>> unspecified as to the presence of type annotations in a TypeMirror 
>> object returned by a Types' method ? And also, specify builder 
>> methods that decorate an existing TypeMirror object with type 
>> annotations ?
>> This approach sidesteps the complexities (alluded to in my prior 
>> mail) of trying to enrich certain methods' results with type 
>> annotations.
>> This approach also exposes that "there's more than one way to do it", 
>> so we should not rush into decisions that ultimately will be part of 
>> JSR 269's next Maintenance Review. Do you keep a to-do list for 269 
>> somewhere?
>> Alex
> ---
> This email is free from viruses and malware because avast! Antivirus 
> protection is active.

More information about the compiler-dev mailing list