JEP325: Switch expressions spec

Kevin Bourrillion kevinb at
Fri Apr 20 18:36:17 UTC 2018

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

> 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

More information about the amber-spec-observers mailing list