Summarizing what I heard: seeing Error is your trigger to "go fix your
classpath and recompile". And implicitly, you're saying: if it is an
exception (no matter how clearly worded about inconsistent assumptions
across classes), it is far less likely to trigger this reaction?
(And, we've told people for years that its OK to add enum constants.)
Yes, but we are deciding to reverse that decision 15 years later.
We're doing that because we think it's worth it, but let's at least be
clear about the fact that that is what we're doing.
Let's back up. Are we really reversing this? Or are we doing
something more subtle?
Is it OK to add enum constants if they are not published across
maintenance boundaries?
Is it OK to add enum constants if you don't use expression switches?
Is it OK to add enum constants if you use expression switches with
explicit defaults?
Suppose you publish an API that has
enum TrafficLight { RED, YELLOW, GREEN }
And I depend on your API with an optimistically exhaustive switch
(OES). Then you add BLUE**
So, who's at fault?
- You, for adding a switch to an enum that is published across a
maintenance boundary?
- Me, for OESing on an enum imported across a maintenance boundary?
- Java, for letting me OES across a maintenance boundary?
(The latter is a new idea, but I think is what you're getting at --
perhaps the rule should be that _within a module_, which is expected to
be co-compiled, its OK to leave off the default, but for "foreign"
enums/sealed types, we're not going to put any faith in the claim of
sealed-ness, and make you handle the default explicitly?
**Note that just _adding_ an enum is not enough to trigger an error.
Someone actually has to pass that enum to me. And I have to switch on
it. And that switch has to be optimistically exhaustive.
