Webrev for making parts of TypeAnnotationPosition immutable

[Werner Dietl]

>> 1. In the type-annotations repository, I added
>>
>> com.sun.tools.javac.code.TypeAnnotationPosition.copy(TypeAnnotationPosition)
>>
>> This makes it a lot easier to create a new type annotation position
>> from an existing one. I previously had this in a Checker Framework
>> utility class, but can't implement it there without constructor
>> access.
>
> That's probably a worthwhile addition.  I will probably add it in a
> later patch (see comments on 2)

I looked at where I use my new "copy" method and they all follow this pattern:

  TypeAnnotationPosition newpos = TypeAnnotationPosition.copy(tapos);
  newpos.location = tapos.location.append(new
      TypePathEntry(TypePathEntryKind.TYPE_ARGUMENT, arg));

That is, I only want a copy to modify the location array.
This update won't work once "location" is final.
So instead of the copy method, for our use case, it would be enough to
have a method "appendLocation":

  TypeAnnotationPosition newpos = tapos.appendLocation(new
      TypePathEntry(TypePathEntryKind.TYPE_ARGUMENT, arg));

that creates a new TAP with the path entry appended.


> We discussed this amongst the javac team, actually.  It's probably best
> to wait until the end of the roadmap before importing any changes and
> running Checkers.  The reason is that I am trying to make these changes
> as incremental as possible, but in reality they are all steps in a
> rather significant change, and I think there would be a lot of needless
> effort to try to keep checkers in sync with all the intermediate states.

What timeframe are we talking about here? Is it several days or months?
I like to keep jsr308-langtools somewhat in sync with jdk9/dev.

cu, WMD.

-- 
http://www.google.com/profiles/wdietl