-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Enhanced Switch] ECJ tolerates fall through to default from a case with pattern label while javac rejects it. #3318
Comments
From naive user point of view: why is this illegal? I mean not JLS but common sense. In the default case we don't assume some specific type, do we? |
Good question. This looks like a javac defect actually. To be confirmed by closer study and second opinion. 14.11.1 Switch Blocks: ... It is a compile-time error if, in a switch block that consists of switch labeled Operative phrase is On the other hand attempt to use the pattern binding from the prior case is clearly an error and is rejected:
elicits Summary, this should be investigated as a difference vis a vis javac with likely blame on javac. |
Actually, upon re-reading, I feel this is a ECJ defect :) from a purely technical wording standpoint. The statement
So both boxes are ticked - ergo program is illegal. To answer why it is illegal, you can reach the sysout through two arcs, one defining a pattern binding and one without. If it were legal, you won't know how you reached that place and so whether the pattern binding is definitely assigned or not. Attempting to use the pattern binding (which itself is disallowed correctly by ECJ but that is a separate matter) will result in indeterminate behavior. |
But if we don't use pattern binding we should be fine (from naive user point of view)? |
True. But that makes the pattern match binding variable initialization into redundant/dead code and that would be my take on why it is illegal. If you instead used '_' as the binding variable it should be fine. |
For example, this compiles fine with both compilers:
That said, javac also shows inconsistent behavior: This one compiles fine with javac from JDK23:
If you comment out the first println it will be rejected. But the presence or absence of that println statement doesn't alter the fall through status into the default case. |
Found by code inspection:
This program is rejected by javac (
illegal fall-through from a pattern
) while ECJ compiles it:The text was updated successfully, but these errors were encountered: