RFR: JEP 360: Sealed Types (Preview)

[Ty Young]

On 4/13/20 11:03 AM, Vicente Romero wrote:
> Hi all,
>
> The sealed types JEP was already reviewed a while back when we were 
> planning to include it in JDK14. It finally fell off that boat but it 
> is being considered now for JDK15. There have been some changes since 
> then mostly related to subtypes of a sealed type. Before we were 
> planning to infer finality, sealness or non-sealness in the subtypes. 
> We steered away from that direction in favor of explicit declaration 
> at the subtype. I would like to ask for another review of the current 
> version of the JEP that reflects these changes. The JEP is at [1] and 
> the last version of the spec is at [2],
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8227043
> [2] 
> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200228/specs/sealed-types-jls.html


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. That seems like such an incredibly 
small percentage of use cases. Seemingly only time this feature can be 
used without potentially negatively impacting potential API abstractions 
is internal interfaces/classes only.


Case in point, my abstraction for Project Panama's FMA(Foreign Memory 
Access)[1] wherein instead of just implementing FMA's "MemoryAddress" 
interface so that abstractions can be passed to functions directly 
instead of having a getter, I need to create yet another interface that 
sits under everything else which has a getter for a MemoryAddress.


Almost nothing within this abstraction layer can benefit from memory 
flattening(interface sealing is a requirement for flattening AFAIK) 
because my abstraction layer API allows interfaces to be implemented by 
any other library, just as you can redefine types in C[2]. If Java had 
the ability to redefine objects by applying additional type-safe names 
on existing types(or interface implementations) this might be mitigated 
somewhat, but it doesn't.


Also in agreement with Alex on the JEP page. Can JEP pages please be 
written in an easily mentally digestible way so Joe average can 
understand them? The same goes for the Hidden Classes JEP.


[1]https://github.com/BlueGoliath/Crosspoint 
<https://github.com/BlueGoliath/Crosspoint>

[2]https://github.com/BlueGoliath/Goliath-Nvidia-Bindings/blob/master/modules/org.goliath.bindings.nvml/src/main/java/org/goliath/bindings/nvml/structs/nvmlMemory_t.java