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

[Maurizio Cimadamore]

On 18/06/18 19:17, Vicente Romero wrote:
> Hi Bernard,
>
> On 06/18/2018 09:44 AM, B. Blaser wrote:
>> Honestly, I find 'TypeVar.getBound()' a bit heavy and not compliant
>> with the existing 'TypeVar.baseType()' naming.
>> But if everybody agrees with 'getBound()/setBound()' we can change it.
>
> I would prefer get/set but it's just a personal opinion so your call, 
> I'm OK with any
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 (which would mean, given the late stage, postpone to 12).

Opinions?

Maurizio
>
>>
>> What should we do?
>> Bernard
>
> Vicente
>
>>
>> On 18 June 2018 at 02:53, Vicente Romero <vicente.romero at oracle.com> 
>> wrote:
>>> bike shedding: shouldn't it be getBound / setBound instead of bound /
>>> setBound
>>>
>>> Vicente
>>>
>>>
>>> On 06/16/2018 08:13 AM, B. Blaser wrote:
>>>> I've attached the nomenclature change you suggested.
>>>> I agree that 'setBound()' is more expressive.
>>>> Tier1 is still OK.
>>>>
>>>> Cheers,
>>>> Bernard
>>>>
>>>> On 14 June 2018 at 19:03, Maurizio Cimadamore
>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>> Looks ok, I think I'd rather prefer setBound to bound(arg), as the 
>>>>> name
>>>>> you
>>>>> chose doesn't make assignment explicit.
>>>>>
>>>>> Long term, I think we should find ways to avoid mutating the bound 
>>>>> after
>>>>> creation... but I did some experimental work on this, and it's not a
>>>>> piece
>>>>> of cake, as you often need mutation when handling recursive bounds 
>>>>> - e.g.
>>>>> set some initial bound first, then do a subst and set final bounds 
>>>>> later
>>>>> (I
>>>>> think there's a bunch of methods in Types that use this idiom).
>>>>>
>>>>> Maurizio
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 13/06/18 11:09, B. Blaser wrote:
>>>>>> Here it is, in attachment.
>>>>>> It completely privatizes and virtualizes 'TypeVar.bound'.
>>>>>>
>>>>>> Apologies for not providing a web-rev, this is still on my to-do 
>>>>>> list...
>>>>>>
>>>>>> Any feedback is welcome (tier1 is OK),
>>>>>> Bernard
>>>>>>
>>>>>> On 11 June 2018 at 20:42, B. Blaser <bsrbnd at gmail.com> wrote:
>>>>>>> That's what I thought too but I wanted a confirmation before 
>>>>>>> doing the
>>>>>>> whole job...
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bernard
>>>>>>>
>>>>>>> On 11 June 2018 at 19:23, Maurizio Cimadamore
>>>>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>>>>> I think this patch is a good start, but to be complete, we'd 
>>>>>>>> need to
>>>>>>>> completely virtualize access on the 'bound' field, otherwise we 
>>>>>>>> risk
>>>>>>>> turning
>>>>>>>> this into a whack-a-mole exercise. There are e.g. 30 usages in 
>>>>>>>> Types
>>>>>>>> alone,
>>>>>>>> each of those could lead to issues with type annos.
>>>>>>>>
>>>>>>>> Maurizio
>>>>>
>