RFR: JEP 360: Sealed Types (Preview)

[Ty Young]

On 4/13/20 8:52 PM, Brian Goetz wrote:
>
>>
>> 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.)


The "why" doesn't really matter here, IMO, but I digress. What you refer 
to as "security" in the linked document(unless I'm missing something, I 
ctrl+f searched and read it and what came after) is simply people not 
implementing(or the fear thereof) the interface correctly. People do 
this all the time. Heck, even official JDK classes don't follow the 
interfaces that they implement(unmodifiableList).


So are widely implemented and abused interfaces like List going to be 
sealed now too? This seems like a slippery slope that could break 
existing code if implemented.


>
> *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.


This may be a bit unfair of a question given how in-development 
everything is but... has anyone actually tried converting an existing 
project of reasonable size and complexity to use inline types and/or 
records(AKA more then Point)? Has anyone considered the negative 
implications on people writing higher-level abstractions over inlined types?


As someone who has wrote an abstraction layer over FMA, which i'm told 
will use sealed types, I can say that it's a pain. A "MemoryValue"(part 
of my abstraction) *IS* a pointer(or slice of) to a value stored in 
memory, but because FMA's MemoryAddress interface is going to be sealed, 
I can't implement it so that everything "just works". Is it the end of 
the world? No, of course not. It can be(and is, currently) wrapped, but 
it makes code awkward and foggy as to what is being represented. The 
abstractions are, like cake, a lie.


>
> 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"?


I don't think not caring about the "why" is the same as "not 
understanding" here. Inline types and records are features that while I 
personally don't have to use(nor am I trying to right now, unlike 
Records before), they do impact me and my ability to write code the way 
I(and others, again, new Object()) want. That's what I'm talking about 
here. How they work or why they are used is irrelevant beyond how I'm 
impacted by their use in other people's APIs. It's none of my business.


Also, apparently. all of this is going to increase startup time and 
(presumably) memory, according to a presentation I watched on Valahalla. 
A JavaFX application already consumes enough memory to run Raspbian, the 
official Raspberry Pi OS, multiple times over on my computer. That's 
nothing compared to the memory consumed when using other GCs than G1. 
8GB heap sizes of 32GB is 1/4, and that isn't even the total consumed 
memory, just the heap. Please don't make a bad situation worse.