Enum: difference of behaviour between exhaustive switch vs. using default:

Liam Miller-Cushon cushon at google.com
Wed Dec 11 17:52:34 UTC 2024


I had thought that the difference might be related to the statement not
being an 'enhanced' switch statement (JLS 14.11.2), and how non-enhanced
switch statements are not required to be exhaustive.

14.11.3 says if no switch label applies, and the switch statement is not
enhanced, then it completes normally. So in the case of separate
compilation where a new constant is added to the enum after the switch is
compiled, the variable wouldn't be DA.

Was that the intent here?

On Wed, Dec 11, 2024 at 9:43 AM Jean-Noël Rouvignac <
jean-noel.rouvignac at pingidentity.com> wrote:

> Thank you all!
>
> I agree with Remi, the problem no longer exists when using a switch
> expression.
> I thought I could not do it with our (obviously more contrived) code, but
> I have managed to do it in the end.
>
> That said, after sending the email, I actually wondered if this problem
> was actually linked to the use of the "old switch" statement, and a
> possible lack of understanding of the control flow?
> I am ready to be told "we cannot fix it because of JLS rule 4.5.6.7" or
> something like that.
>
> Thank you again for taking a look at it,
> Jean-Noël
>
>
>
>
> On Wed, Dec 11, 2024 at 3:05 PM Angelos Bimpoudis <
> angelos.bimpoudis at oracle.com> wrote:
>
>> Filed it here: https://bugs.openjdk.org/browse/JDK-8345997
>>
>> Thank you for reaching out!
>> Thx Remi for the minimized example as well.
>> ------------------------------
>> *From:* amber-dev <amber-dev-retn at openjdk.org> on behalf of Remi Forax <
>> forax at univ-mlv.fr>
>> *Sent:* 11 December 2024 13:44
>> *To:* Gavin Bierman <gavin.bierman at oracle.com>
>> *Cc:* Jean-Noël Rouvignac (ForgeRock) <
>> jean-noel.rouvignac at pingidentity.com>; amber-dev <amber-dev at openjdk.org>
>> *Subject:* Re: Enum: difference of behaviour between exhaustive switch
>> vs. using default:
>>
>> Hello,
>> I think it can be reduced to
>>
>> public enum Action { IGNORE, REJECT }
>>
>> private static void bad() {
>>     String s;
>>     switch (getAction()) {
>>         case IGNORE:
>>             s = "foo";
>>             break;
>>         case REJECT:
>>             throw new RuntimeException("REJECTED");
>>     };
>>     System.out.println(s); // <------- variable s might not have been initialized
>> }
>>
>> private static void ok() {
>>     String s = switch (getAction()) {
>>         case IGNORE:
>>             yield "foo";
>>         case REJECT:
>>             throw new RuntimeException("REJECTED");
>>     };
>>     System.out.println(s); // ok !
>> }
>>
>>
>> so there is a bug in DA/DU rules and the workaround is to use a switch
>> expression.
>>
>> Rémi
>>
>> ------------------------------
>>
>> *From: *"Gavin Bierman" <gavin.bierman at oracle.com>
>> *To: *"Jean-Noël Rouvignac (ForgeRock)" <
>> jean-noel.rouvignac at pingidentity.com>
>> *Cc: *"amber-dev" <amber-dev at openjdk.org>
>> *Sent: *Wednesday, December 11, 2024 1:20:15 PM
>> *Subject: *Re: Enum: difference of behaviour between exhaustive switch
>> vs. using default:
>>
>> Could you file this as a bug, and I will take a look?
>>
>> Thanks,
>> Gavin
>>
>> On 10 Dec 2024, at 16:10, Jean-Noël Rouvignac (ForgeRock) <
>> jean-noel.rouvignac at pingidentity.com> wrote:
>>
>> Hello amber-dev experts!
>>
>> I am modernizing our codebase by making it use enhanced / exhaustive
>> switches.
>>
>> In several places, I replaced `default: ` by `case
>> THE_ONLY_UNUSED_ENUM_VALUE:`, except that I am hitting an unexpected
>> difference in behaviour, at least from my point of view.
>>
>> I have reduced the code to the following reproducer (tested on the
>> https://dev.java/playground/), where `main1()` compiles, but `main2()`
>> does not. And yet, I am under the impression both should be equivalent?
>>
>> What do you think?
>> Thanks a lot.
>>
>>
>>
>> import java.io.IOException;
>>
>> class Main {
>>     public enum Action { IGNORE, REJECT }
>>
>>     public static void main(String[] args) {
>>         main1();
>>         main2();
>>     }
>>
>>     private static void main1() {
>>         String s;
>>         try {
>>             s = getValue();
>>         } catch (IOException e) {
>>             switch (getAction()) {
>>                 case IGNORE:
>>                     return;
>>                 default:
>>                     throw new RuntimeException("REJECTED");
>>             }
>>         }
>>
>>         System.out.println(s);
>>     }
>>
>>     private static void main2() {
>>         String s;
>>         try {
>>             s = getValue();
>>         } catch (IOException e) {
>>             switch (getAction()) {
>>                 case IGNORE:
>>                     return;
>>                 case REJECT: // <------------------- Fails compilation
>>                     throw new RuntimeException("REJECTED");
>>             }
>>         }
>>
>>         System.out.println(s); // <------- Main.java:40: error: variable
>> s might not have been initialized
>>     }
>>
>>     static Action getAction() {
>>         return Action.IGNORE;
>>     }
>>
>>     static String getValue() throws IOException {
>>         return "SUCCESS";
>>     }
>> }
>>
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited.
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>>
>>
>>
>>
>
> --
> <https://www.pingidentity.com/> <https://www.pingidentity.com/>[image:
> Ping Identity] <https://www.pingidentity.com/>
> Jean-Noel Rouvignac
> Senior Principal Software Engineer
> jean-noel.rouvignac at pingidentity.com
>
> <https://www.pingidentity.com/en/events/youniverse.html>
> <https://www.pingidentity.com/en/events/youniverse.html>
> <https://www.pingidentity.com/en/events/youniverse.html>
> Connect with us:
> <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>[image:
> Glassdoor logo]
> <https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
>   <https://www.linkedin.com/company/21870>[image: LinkedIn logo]
> <https://www.linkedin.com/company/21870>
> <https://twitter.com/pingidentity>[image: twitter logo]
> <https://twitter.com/pingidentity>
> <https://www.facebook.com/pingidentitypage>[image: facebook logo]
> <https://www.facebook.com/pingidentitypage>
> <https://www.youtube.com/user/PingIdentityTV>[image: youtube logo]
> <https://www.youtube.com/user/PingIdentityTV>
> <https://www.pingidentity.com/en/blog.html>[image: Blog logo]
> <https://www.pingidentity.com/en/blog.html>
> To view our privacy policy, click here
> <https://www.pingidentity.com/en/legal/privacy.html>
> To stop receiving these emails, click here
> <https://4.pingidentity.com/PreferenceCenter.html>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241211/3a31d41c/attachment-0001.htm>


More information about the amber-dev mailing list