RFR: JEP 360: Sealed Types (Preview)

[Maurizio Cimadamore]

On 14/04/2020 01:30, Ty Young wrote:
> 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. 

This discussion has already been covered in [1], where I also give good 
reasons as to why it doesn't make sense to allow for custom memory 
address/segment implementations. These interface implementations are 
really meant to work in synergy with VM abstractions, so we wanna 
reserve the VM/JIT the freedom to make assumption on how the 
implementation of these classes is going to behave. I think it would be 
extremely bad if the safety, deterministic and performance guarantees of 
these API would be rendered invalid by a "non conformant" 
implementation. As you can't write your own MethodHandle or VarHandle, 
the same goes for memory segments and addresses; they are low level 
abstractions whose goal is to provide safe and performant memory access. 
The fact that you disagree with this design decision (and expressed so 
many times in the past) doesn't make sealed types less useful.

Maurizio

[1] - 
https://mail.openjdk.java.net/pipermail/panama-dev/2020-January/007015.html