RFR: 8257037: No javac warning when calling deprecated constructor with diamond [v2]
Remi Forax
forax at univ-mlv.fr
Mon Dec 7 12:44:47 UTC 2020
oops,
you mean Collectors.toList() vs Stream.toList()
Rémi
----- Mail original -----
> De: "Maurizio Cimadamore" <mcimadamore at openjdk.java.net>
> À: "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoyé: Lundi 7 Décembre 2020 13:18:16
> Objet: Re: RFR: 8257037: No javac warning when calling deprecated constructor with diamond [v2]
> On Mon, 7 Dec 2020 11:54:08 GMT, Guoxiong Li
> <github.com+13688759+lgxbslgx at openjdk.org> wrote:
>
>>> The extensive testing revealed at least 10 cases where the compiler is issuing a
>>> new, resolution-related error when it wasn't doing so before - (the errors seem
>>> to have to do with `abstract` methods). As a result I think it's best to go
>>> with your first conservative approach, to avoid troubles. I'll try to
>>> investigate further and come up with a reduced test case for the failing
>>> condition - but that doesn't have to hold up this fix. Thanks!
>>
>> It is a good news that the trouble is found before the integration instead of
>> after the release of JDK16.
>> I revise the code to previous version.
>> Thank your for the review.
>
> Actually, after some more analysis, I discovered that many of the errors were
> unrelated with your fix - and had to do instead with the addition of a new
> default method on Stream, which is causing overload resolution changes in code
> that has static imports on Collectors.
>
> Only one issue remains to be fully triaged - but, being annotation related, I
> think it's unlikely caused by your patch. In other words, I believe both
> patches are likely to be safe. I'm obviously ok with you going ahead with the
> more conservative fix, since you already reverted the code to that version.
>
> I apologize for the back and forth!
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1490
More information about the compiler-dev
mailing list