Draft JEP: Primitive Types in Patterns, instanceof, and switch (Second Preview)

[Stephan Herrmann]

Am 30.08.24 um 23:31 schrieb Remi Forax:
> ----- Original Message -----
>> From: "Stephan Herrmann" <stephan.herrmann at berlin.de>
>> To: "Brian Goetz" <brian.goetz at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.org>
>> Sent: Friday, August 30, 2024 9:58:42 PM
>> Subject: Re: Draft JEP: Primitive Types in Patterns, instanceof, and switch (Second Preview)
> 
> Hello Stephan,
> 
>> Why should it be a bug to inform the user about bad style?
>>
>> Note, that users are free to chose the severity of this problem as one of Error,
>> Warning, Info or Ignore.
> 
> For me this message by ecj is misleading :
> - you may want to capture a wildcard bounded by Integer using a named type parameter,
>      List<? extends Integer> list = ...

and what is the use of the wildcard which can represent exactly one type?

>      capture(list);
> 
>      <T extends Integer> void capture(List<T> list) {
>        ...
>      }
> 
> - the JLS explicitly says that removing final from a class is a backward compatible change, so maybe in the future the final class will not be a final anymore. That's why a class being final is not something which is part of the type system.

That's a good point. So this motivates why it is not a mandatory error.

But I have never seen anyone use "extends FinalClass" for the purpose of 
compatibility with future versions of that class.

So, it's not a hard error, but in most cases users are better off with 
simplifying the code.

Meanwhile I found one meaningful usage:
	<T extends @Nullable Integer>
which some tools interpret as having two instantiations:
	@Nullable Integer
	@NonNull Integer
:)


>>
>>
>> Am 30.08.24 um 21:55 schrieb Brian Goetz:
>>> That's probably a (well intentioned!) ECJ bug!
>>>
>>>
>>> On 8/30/2024 3:52 PM, Stephan Herrmann wrote:
>>>> Thanks for clarifying.
>>>>
>>>> FWIW ecj informs me:
>>>>
>>>> The type parameter T should not be bounded by the final type Integer. Final
>>>> types cannot be further extended
>>>>
>>>> :)
>>>>
>>>> Am 30.08.24 um 21:47 schrieb Brian Goetz:
>>>>> I had exactly the same confusion when I read those words.  Alex set me straight.
>>>>>
>>>>>       <T extends Integer> int asInt(T t) { return t; }
>>>>>
>>>>> Here, we go from T to Integer (a widening reference conversion), then to int
>>>>> (an unboxing conversion).
>>>>>
>>>>> On 8/30/2024 3:44 PM, Stephan Herrmann wrote:
>>>>>> The other day I stumbled upon this in the JLS changes for the first preview
>>>>>> (JEP 455):
>>>>>>
>>>>>> * a widening reference conversion followed by an unboxing conversion
>>>>>> * a widening reference conversion followed by an unboxing conversion, then
>>>>>> followed by a widening primitive conversion
>>>>>>
>>>>>> I fail to imagine any type that can be widened to a boxing type. What's
>>>>>> going on here?
>>>>>>
>>>>>> best,
>>>>>> Stephan
>>>>>>
>>>>>>
>>>>>> Am 30.08.24 um 15:55 schrieb Angelos Bimpoudis:
>>>>>>> Dear experts,
>>>>>>>
>>>>>>> A draft JEP for the second preview of primitive types in patterns,
>>>>>>> instanceof, and switch is now available. We propose to preview it for a
>>>>>>> second time with no changes relative to JDK 23. This feature aligns what
>>>>>>> instanceof and pattern matching mean across all types. This second preview,
>>>>>>> unchanged, gives ample time to amber experts to express their feedback.
>>>>>>>
>>>>>>> https://bugs.openjdk.org/browse/JDK-8335876
>>>>>>>
>>>>>>> Let us know of your feedback.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Angelos
>>>>>>
>>>>>
>>>>