Draft JEP on Primitive types in patterns, instanceof, and switch

Remi Forax forax at univ-mlv.fr
Fri Jan 27 11:06:30 UTC 2023


----- Original Message -----
> From: "Ron Pressler" <ron.pressler at oracle.com>
> To: "Stephen Colebourne" <scolebourne at joda.org>
> Cc: "amber-dev" <amber-dev at openjdk.org>
> Sent: Friday, January 27, 2023 9:59:36 AM
> Subject: Re: Draft JEP on Primitive types in patterns, instanceof, and switch

>> On 26 Jan 2023, at 22:01, Stephen Colebourne <scolebourne at joda.org> wrote:
>> 
>>  In this context, `42` is *not* an `int` at all - it is a literal. There is no
>>  conversion here,
>> `42` is typed as a `byte` because of the assignment. `42` is never, at
>> any stage, an `int`.
> 
> 
> See JLS §3.10.1 and §5.2.
> 
> 
>> There is simply no comparison here. Dog and Animal are subtypes of
>> Pet, a concept that has been baked into the language since day one,
>> and is fully understood by all. By contrast, there is absolutely no
>> subtyping relationship between int, byte and short
> 
> 
> Whether or not there’s any comparison here is debatable, but until, like,
> five minutes ago switch couldn’t switch on types, and now that switch *must*
> switch on type relationships is an eternal cornerstone of Java?
> 
> Also, you may want to look at JLS §4.10.1.
> 
> 
>> saying that the language should now examine not only the type but also
>> the value of the instance in order to determine flow control.
> 
> 
> I believe switch has examined values to determine control flow for quite some
> time now.
> 
> 
>> The root cause of the issue here is trying to treat Object hierarchy
>> conversion and conversion between different primitive types as being
>> somehow equivalent.
> 
> 
> Not equivalent. Rather, the JEP generalises patterns into a concept that
> encompasses
> both. It reinterprets what patterns are about: "Despite having been restricted
> to
> reference types, instanceof is in principle about asking whether an upcoming
> cast of a
> value to a type would succeed without loss of information or error.”
> 
> Given that patterns, as a new general concept, are all about reinterpreting old
> concepts
> and extrapolating from them, pointing out that other extrapolations are possible
> is not
> exactly calling out the emperor’s new clothes.

The problem with extrapoling/re-interpreting is where to stop, where to draw the line.
Most languages that have C as ancestor have tried to separate the different casts into different categories, considering using the same syntax for different kind of casts as a mistake. 
Re-interpreting "instanceof" as a question if any casts will succeed and not just reference casts is a huge leap of faith that feels backward.

Generations of Java developers have a pretty good grasp of the difference between subtyping and primitive conversions, this proposal acts as a wrecking ball and shatter that.
By example, you can not override a method that returns a double with a method that returns an int because overriding is about subtyping relationship, not conversion (for the history, Neal Gafter had implemented method overriding that allow primitive conversions in javac in one of the early versions of Java 1.5 but to it was decided to not go that path).

I agree that revisiting concepts is something we have to do, but breaking the difference between subtyping and primitive conversions for a corner case, in isolation, is a decision hard to understand.

> 
> — Ron
> 
> P.S.
> 
> The tone of your email was a jot hysterical, which did not aid comprehension and
> was implacably annoying.

Stephen is like a lot of us, invested in Java.

> Maybe tone it down next time

Rémi


More information about the amber-dev mailing list