Enum: difference of behaviour between exhaustive switch vs. using default:
Jean-Noël Rouvignac
jean-noel.rouvignac at pingidentity.com
Wed Dec 11 22:47:38 UTC 2024
Yes, I think you nailed it Liam.
> 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.
JLS 14.11.1.1 "Exhaustive Switch Blocks" section says switch statements can
be exhaustive and IIUC this is the case here.
> 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?
Indeed, the automatically inserted `default:` clause only applies to switch
expressions (as per JEP 361 "Switch Expressions" in the "Exhaustiveness"
section).
Switch statements, on the other side, are not _required_ to be or stay
exhaustive, even in the face of separate compilation.
Therefore, the error "variable s might not have been initialized" in the
code example looks correct to me, although it can be troubling when one
does not think about separate compilation.
Good thinking. Thank you!
On Wed, Dec 11, 2024 at 6:52 PM Liam Miller-Cushon <cushon at google.com>
wrote:
> 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.*
>
>
--
<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/babf1173/attachment-0001.htm>
More information about the amber-dev
mailing list