understanding the concept

[Tiam Bezalel]

hi, please, i would like to understand why the code below creates a compile error. please explain to me the principle behind it. thanks.

final String[] arr = { "L", "R", "T", "B" };
String str = "t";
switch (str) {
    case arr[0]:
        System.out.println("LEFT");
        break;
    case arr[1]:
        System.out.println("RIGHT");
        break;
    case arr[2]:
        System.out.println("TOP");
        break;
    case arr[3]:
        System.out.println("BOTTOM");
        break;
    default:
        System.out.println("NA");
        break;
}

[Jeanne Boyarsky]

Tiam,
You need to have constants in the case. So "L" is ok, but arr[0] is not.

[Tiam Bezalel]

Jeanne Boyarsky wrote:Tiam,
You need to have constants in the case. So "L" is ok, but arr[0] is not.

thank you for the answer but please i want more explanation to understand. i want to understand the behaviour of the compiler. why the compiler behaves like this?

[Jeanne Boyarsky]

You can think of it like the compiler turns the switch into if statements for you. But it needs to know what value to put. The array value can change so the compiler doesn't know what to put. You are probably still wondering why. It's how they optimize it. If the value can change, it can't be stored directly in the bytecode.

[Tiam Bezalel]

Jeanne Boyarsky wrote:You can think of it like the compiler turns the switch into if statements for you. But it needs to know what value to put. The array value can change so the compiler doesn't know what to put. You are probably still wondering why. It's how they optimize it. If the value can change, it can't be stored directly in the bytecode.

based on my research for the 1Z0-808 exam,
The switch expression can accept the following elements: 

char or Character, 

byte or byte, 

short or short, 

int or Integer, 

An enum only in Java 6 and later, 

A String expression only from Java 7 onwards

Do all case expressions have to be constants at compile time? Does the compiler handle case expressions as constants?
thanks a lot

[Jeanne Boyarsky]

Compile time constants. That means the compiler can determine the value rather than there being a "final" keyword.

[Simon Roberts]

Jeanne Boyarsky wrote:Compile time constants. That means the compiler can determine the value rather than there being a "final" keyword.

I'm not clear what you mean by that comment Jeanne, final values of primitive and String types are compile time constants, as are expressions using them, and both are acceptable as case values. The below works fine:

    final int x = 99;
    int y = 99;
    switch (y) {
      case x:
        System.out.println("99");
        break;
      case x + 1:
        System.out.println("100");
        break;
   }

Perhaps you meant something else, and I simply missed the point?

As to "why", there are perhaps three reasons, first, "it's the language specification" (one-a would be "that's the way C/C++ did it), second, a case statement (at least at Java 11) compiles to a jump table, not a calculation or series of tests. The third reason, a matter of personal opinion, is that having expressions in the case block makes it harder to read what is going on.

[Jeanne Boyarsky]

The original poster's example was an array, not and int or String.

Thumbs up on the "because the spec said so" point!

[Stephan van Hulst]

The most important reason is that the compiler can ensure that the cases are mutually exclusive, and therefore there will be no ambiguity what case will be executed after the switch expression evaluates.

I think what Jeanne meant is that variables can act as compile time constants if they're effectively final, in which case using the final keyword is not strictly necessary.

[Tiam Bezalel]

Stephan van Hulst wrote:The most important reason is that the compiler can ensure that the cases are mutually exclusive, and therefore there will be no ambiguity what case will be executed after the switch expression evaluates.

I think what Jeanne meant is that variables can act as compile time constants if they're effectively final, in which case using the final keyword is not strictly necessary.

hi,
I finally concluded this:

"if the compiler is sure that the "case expression" will not change during execution, there will be no compiler error. but it suspects that the case expression may vary, so it complains about a potential value variation."

that's how I understand it.

thanks

[Simon Roberts]

More than that. The *compiler* must be able to calculate the case value. It's literally a compile-time constant. It's not a variable in any way.

But when you get past the certification exam, know that there's a whole new case mechanism and much of this discussion becomes true only for the traditional form.

[Tiam Bezalel]

Simon Roberts wrote:More than that. The *compiler* must be able to calculate the case value. It's literally a compile-time constant. It's not a variable in any way.

But when you get past the certification exam, know that there's a whole new case mechanism and much of this discussion becomes true only for the traditional form.

hi,

Please can you explain the new case mechanism to me? I don't want to have any surprises at the exam (1Z0-808)

thanks

[Paul Anilprem]

Simon is probably talking about switch expressions but you don't have to worry about it for the 1z0-808 exam because this exam is based on Java 8 and the new switch expressions feature has been available only since Java 12.

[Simon Roberts]

Paul Anilprem wrote:Simon is probably talking about switch expressions but you don't have to worry about it for the 1z0-808 exam because this exam is based on Java 8 and the new switch expressions feature has been available only since Java 12.

Actually I was talking about pattern matching, which isn't even fully released in Java 19, it's still a preview. But exactly, it's not relevant, which was why I said "... when you get past the certification ..."

That said, for anyone taking the Java 17 exam (1Z0-829) the switch expression and arrow-form material (none of which has also not been discussed here) are relevant. But none of that matters to you since you have mentioned that you're taking 808.

[Tiam Bezalel]

Simon Roberts wrote:

Paul Anilprem wrote:Simon is probably talking about switch expressions but you don't have to worry about it for the 1z0-808 exam because this exam is based on Java 8 and the new switch expressions feature has been available only since Java 12.

Actually I was talking about pattern matching, which isn't even fully released in Java 19, it's still a preview. But exactly, it's not relevant, which was why I said "... when you get past the certification ..."

That said, for anyone taking the Java 17 exam (1Z0-829) the switch expression and arrow-form material (none of which has also not been discussed here) are relevant. But none of that matters to you since you have mentioned that you're taking 808.

thanks

[Mike Simmons]

Simon Roberts wrote:More than that. The *compiler* must be able to calculate the case value. It's literally a compile-time constant. It's not a variable in any way

Well, except in the sense that a "variable" in Java can be a constant variable, despite the linguistic non sequitur.  A variable in Java isn't a "thing that varies" - it's a symbol that refers to a value.  Which often may vary, but may be a constant.  So you can have a case value that's a variable which is also a compile-time constant.  

Of course that's not what Simon was talking about, and he's absolutely right in his main point that case values need to be compile-time constants.  For now.  But I wanted to clarify in case anyone reads it and thinks you can't have a constant variable as a case value - yes, you can.

[Simon Roberts]

Mike Simmons wrote:
Well, except in the sense that a "variable" in Java can be a constant variable, despite the linguistic non sequitur.

Absolutely right, of course. I should have said something like "not able to vary in any way"

I'm always intrigued that in math equations we call "y" a variable, but it's not so much a variable as a perhaps not yet resolved value, at least for any given input value (of "x" presumably ) At least I find this idea helpful when trying to teach use of immutable data in functional programming!

[Campbell Ritchie]

Simon Roberts wrote:. . . . The *compiler* must be able to calculate the case value. . . ..

A lookup table is created and populated at compile time, which allows for very fast execution, but requires compile‑time constants. That means that Integers, Shorts, Bytes, and Characters are not permissible as cases because only primitives and Strings can be compile‑time constants.
I thought enum elements were permitted as cases in Java5.

[Simon Roberts]

You're right, absolutely, enum constants (without their class prefix, which I always think is odd) are allowed since Java 5.