RFR: JDK-8193367: Annotated type variable bounds crash javac
B. Blaser
bsrbnd at gmail.com
Mon Jun 18 20:52:45 UTC 2018
On 18 June 2018 at 22:09, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
>
> 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?
Personally I'm OK with 'getBound()/setBound()' and I suggest to move
forward with the fix to 11 as it doesn't seem risky and corrects a
variety of potential failures with annotated type variable bounds.
Further cleanup and consolidation should be postponed to 12 to
minimize the impact of the fix, I think.
If we all agree, I can provide an updated patch with 'getBound()/setBound()'?
Bernard
> Maurizio
>
>>
>>>
>>> What should we do?
>>> Bernard
>>
>>
>> Vicente
More information about the compiler-dev
mailing list