JEP325: Switch expressions spec

Kevin Bourrillion kevinb at
Fri Apr 20 18:49:31 UTC 2018

I was proposing `default, case null` above, in order to keep `default`
parallel with `case` instead of appearing like it can be subordinate to it.
Put another way `case null, default` looks like you can remove the `null, `
from it, just as you could in other labels.

However, once that's allowed, then people would automatically try `case
null, default` anyway. Whichever way we wanted, they would try both ways.

This small mess constitutes one of the valid arguments (to me) for delaying
this sad change as long as possible. :-)  However, I admit I still need to
make progress understanding exactly how big the *upside* is in the world of
patterns. You've explained it patiently a few times and I probably just
need to reread it.

On Fri, Apr 20, 2018 at 11:40 AM, Brian Goetz <brian.goetz at>

> One thing that is relevant to the short term is that now that we killed
> mixed labels, we'd have to have a way to say "case null or default" in
> arrow world.  The least stupid thing seems to be to allow default to be
> tacked on to a comma-separated case list as if it were a pattern:
>     case A -> s1;
>     case null, default -> s2;
> since you can no longer say:
>     case A -> s1;
>     case null:
>     default:
>         s2;
> On 4/20/2018 2:36 PM, Kevin Bourrillion wrote:
> On Fri, Apr 20, 2018 at 10:45 AM, Brian Goetz <brian.goetz at>
> wrote:
>> So, all I'm asking is: can we make this particular change atomically with
>> patterns itself, not before? I believe that the change has negative value
>> until then because it is too easy to use it to write bugs. (If this means
>> that long and boolean also wait until then, I don't think anyone would
>> really mind. If necessary I can look up how common simulated-switch-on-
>> long happens in our codebase, but we all know it won't be much.)
>> The extra primitive types are separable, so could be deferred.  I'd be
>> less sanguine about adding long now but not float.
> Agreed, it would seem weird to keep adding more piecemeal over and over.
> Separately but similarly, the merits of case null: have also been
>> justified almost entirely in the context of patterns. Without patterns, I
>> believe the benefits are far too slight. We studied six digits' worth of
>> switch statements in the Google codebase, using a *liberal*
>> interpretation of whether they are simulating a null case, and came up with
>> ... 2.4%.  (You will find that suspicious as hell, since it's the exact
>> same percentage I cited for fall-through yesterday, but I swear it's a
>> coincidence!)
>> More nervous about this.  Would rather start the education curve on this
>> earlier. And there are plenty of existing switches that are wrapped with
>> "if target != null" that would be clearer/have less needless repetition by
>> pushing the case null into the switch.
> Er - just clarifying that this is the *same* 2.4% that I am referring to.
> Of course, numbers will vary (and I concede that we are quite toward the
> null-hostile end of the spectrum in our general dev practices). Still, I'm
> sure we would not be making this change for this reason alone, so it really
> is about this issue of "starting the education curve earlier". Trying to
> figure out how much that matters.
> For what it's worth, Guava took the position at the start that, since
> working with null is risky and problematic, it's *okay* if code that
> deals with null is uglier than code that doesn't. It's only natural, so we
> don't bend over backwards to try to smooth it over. If that decision has
> played *some* *small* part in helping shift the world away from rampant
> overuse of null everywhere, we wouldn't regret it a bit. I think JDK
> collections post-1.4 could say the same thing to a larger degree. Okay, I
> guess this is just the "moral hazard" argument stated a different way -
> sorry.
> (Full disclosure: if you accuse me of wanting more time before `case
> null:` lands just so I have more time to try to talk us out of it
> completely, I suppose have no defense to that. :-))
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at

Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at

More information about the amber-spec-observers mailing list