RFR: JEP 360: Sealed Types (Preview)

[Brian Goetz]

>
> This seems to be yet another extremely targeted feature that will only 
> ever be applicable to API writers that don't want their interfaces to 
> be implemented outside of their API. 

I think you have mostly missed the points of this feature.  I say 
"points" because this feature actually has two motivating use cases, one 
of which you have failed to imagine, and the other of which you have 
underestimated.  I'll take them in turn.

*Controlling implementations.*  This is the part that you imagined, but 
underestimated.  It is not simply a matter of authors "not wanting" 
their interfaces to be implemented; it is about enabling APIs to not 
have to choose between good OO abstractions and security.  A sealed 
hierarchy allows an API designer to ensure that they know where all the 
implementations are, and therefore can rely on the fact that they 
properly enforce their invariants, security constraints, etc.  The JDK 
has many APIs that can benefit from such a mechanism, but other 
libraries can take advantage of it too.  But even if _only_ the JDK 
needed this, it would still be justifiable to consider such a feature on 
the basis of better platform security, fewer bugs, more flexibility for 
future expansion, etc.  But fortunately user libraries get the benefit 
of it too.  (The sealing information also provides useful information 
with which the JIT can more reliably perform CHA-based optimization; 
Valhalla takes advantage of this.)

*Algebraic sum types.*  This is the more broadly useful part, and the 
one that you missed, though it was outlined in

     https://cr.openjdk.java.net/~briangoetz/amber/datum.html

(and other places.)  Sum types are familiar to functional programmers, 
but they are relatively new to Java developers.  They allow type 
hierarchies to include exhaustiveness constraints, which can be used by 
the language to provide better type checking.  And they work 
particularly well with _product types_ (records) and pattern matching; 
switching over a sum of products (sealed interface whose subtypes are 
records) with deconstruction patterns is a powerful construct that is 
both safer and more compact than the alternatives we have today.   Since 
we are delivering in phases, it may take a few versions for the full 
benefit to be available, but the sub-features are still useful on their 
own, hence the roll-out order we have chosen.

It's entirely forgivable that you missed the point, and we're happy to 
help clarify -- but less forgivable that you responded in the 
unconstructive way that is, sadly, characteristic of too much of your 
participation in OpenJDK.  When you don't understand something, consider 
starting with "I don't get it, can you please explain it", rather than 
"This is dumb" or "You guys blew it again"?