Am 30.08.24 um 23:31 schrieb Remi Forax:
----- Original Message -----
From: "Stephan Herrmann" <[email protected]>
To: "Brian Goetz" <[email protected]>, "amber-spec-experts"
<[email protected]>
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
