RFR: 8332463: Byte conditional pattern case element dominates short constant case element

[David Alayachew]

Then maybe I am not following along here.

The link you sent says this.

> a boxing conversion followed by a widening reference conversion (5.1.5
<https://docs.oracle.com/javase/specs/jls/se22/html/jls-5.html#jls-5.1.5>)

Isn't what I described just an abbreviated version of this casting context?

Namely, byte --> Byte --> Integer

And even if not (I would like to know why not), my other question wasn't
answered -- why not allow this?

Specifically, I cannot imagine a single value of byte that could not be
representable as Integer.

I guess, what does this lack of ability grant us that we would lose if we
made it possible? To go straight from byte to Integer, I mean.

On Tue, May 21, 2024, 5:10 AM Angelos Bimpoudis <
angelos.bimpoudis at oracle.com> wrote:

> The reason is that according to Casting Contexts/Section 5.5 (or Testing
> Contexts in JDK 23/Section 5.7 which is very similar to casting contexts)
> not only it is not unconditionally exact but there is no conversion at all
> that can support byte to Integer. If there were one, we would see a bullet
> that says: a widening primitive conversion followed by boxing.
>
> The permitted conversions are the ones listed in Chapter 5.5 or 5.7 in the
> accompanying spec diff –
> https://cr.openjdk.org/~abimpoudis/instanceof/jep455-20240424/specs/instanceof-jls.html#jls-5.7
> .
>
> This is also evident by trying to do the cast in JShell:
>
> jshell> byte b = (byte) 42
> b ==> 42
>
> jshell> (Integer) b
> |  Error:
> |  incompatible types: byte cannot be converted to java.lang.Integer
> |  (Integer) b
> |            ^
>
> Note, that while dominance checks the relation between two case labels,
> those two case labels can be independently applicable to the selector type.
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* 21 May 2024 00:12
> *To:* Aggelos Biboudis <abimpoudis at openjdk.org>
> *Cc:* compiler-dev <compiler-dev at openjdk.org>
> *Subject:* Re: RFR: 8332463: Byte conditional pattern case element
> dominates short constant case element
>
> I understand the first 2 cases, but not the third. How is byte -> Integer
> not unconditionally exact? What possible scenario could occur where one
> would lose data?
>
> On Mon, May 20, 2024, 4:31 AM Aggelos Biboudis <abimpoudis at openjdk.org>
> wrote:
>
> It seems that the compiler introduced a rule that does not exist in the
> spec. The fix is simple, and it will fix the behaviour of JDK 23 according
> to the spec. For example the following is accepted by JDK 22 and needs to
> continue to be accepted by JDK 23:
>
>
> public static int test() {
>     Byte i = (byte) 42;
>     return switch (i) {
>         case Byte ib   -> 1;
>         case (short) 0 -> 2; // OK - not dominated
>     };
> }
>
>
> Similarly for primitive type patterns:
>
>
> public static int test() {
>     Byte i = (byte) 42;
>     return switch (i) {
>         case Byte ib  -> 1;
>         case short s  -> 2; // Also not dominated since there is no
> unconditionally exact conversion from short to Byte
>     };
> }
>
> public static int test() {
>     int i = 42;
>     return switch (i) {
>         case Integer ib -> 1;
>         case byte ip    -> 2; // Also not dominated since there is no
> unconditionally exact conversion from byte to Integer
>     };
> }
>
> -------------
>
> Commit messages:
>  - 8332463: Byte conditional pattern case element dominates short constant
> case element
>
> Changes: https://git.openjdk.org/jdk/pull/19301/files
>   Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19301&range=00
>   Issue: https://bugs.openjdk.org/browse/JDK-8332463
>   Stats: 104 lines in 5 files changed: 94 ins; 7 del; 3 mod
>   Patch: https://git.openjdk.org/jdk/pull/19301.diff
>   Fetch: git fetch https://git.openjdk.org/jdk.git
> pull/19301/head:pull/19301
>
> PR: https://git.openjdk.org/jdk/pull/19301
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20240521/3d852729/attachment-0001.htm>