RFR: JDK-8193367: Annotated type variable bounds crash javac

[Maurizio Cimadamore]

I'm a bit confused (but it could also be because I'm misremembering) - 
wasn't the whole point of the exercise to have cloned type variables to 
piggy back on the clonee's getUpperBound?

In the patch I see this:

@Override
1640         public TypeVar cloneWithMetadata(TypeMetadata md) {
1641             return new TypeVar(tsym, getUpperBound(), lower, md) {
1642                 @Override
1643                 public Type baseType() { return TypeVar.this.baseType(); }
1644             };
1645         }


Which doesn't seem better than the current code - e.g. the upper bound 
is fetched when the cloned var is created, so, if the bound is updated 
after the fact, such changes will not be reflected in the clones var?

Maurizio

On 24/01/2019 13:52, B. Blaser wrote:
> On Mon, 18 Jun 2018 at 22:09, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>> Also, note that there's another related method: getUpperBound. This is
>> *almost* like getBound() but it does few extra checks on top.
>>
>> While, I'm confident that this patch is not risky, I'm a bit worried
>> that exposing yet another accessor will create confusion to clients -
>> should they use Type::getUpperBound, Types::upperBound, or the new
>> Type::bound/getBound?
>>
>> I wonder if we need some consolidation here before moving forward with
>> the fix
> Done some weeks ago:
>
> http://cr.openjdk.java.net/~bsrbnd/jdk8193367/webrev.00/
>
> Tier1 was OK at that time, thoughts?
> Thanks!
>
> Ciao,
> Bernard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190124/36d264af/attachment.html>