RFR: JDK-8298476: Unseal FinalReference<T>

[Bernhard Urban-Forster]

On Fri, 9 Dec 2022 17:40:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The change in [JDK-8283415](https://bugs.openjdk.org/browse/JDK-8283415) made use of the now available `sealed` keyword for `FinalReference<T>`.
>> 
>> Unfortunately this introduced a problem for the Espresso VM (Java on Truffle): Since Espresso is written in Java it uses the functionality of the "Host VM" to implement finalization. It does that however by [introducing a new subclass of `FinalReference<T>`](https://github.com/oracle/graal/blob/f195395329fba573afc6f81c5e70a18ac334dd10/espresso/src/com.oracle.truffle.espresso/src/com/oracle/truffle/espresso/ref/ClassAssembler.java#L85-L113) which does not work anymore with the changes made in JDK-8283415. We cannot use `Finalizer` itself because we want to inject an additional "Guest object".
>> 
>> Making `FinalReference<T>` `non-sealed` would simplify things for Espresso. Before pursuing other more involved solutions I thought I would ask how strongly the maintainers of core-libs feel about such a change. Would that be okay? Are there any implications for the GC for such a change?
>
> It's unfortunate that Espresso has been extending this JDK internal class but the sealing of the Reference class hierarchy, and not reverting it to be open via a JDK internal class, is good for platform integrity and security. It would be a shame to change that as it amounts to making this class be a kind of supported interface. It's a slippery slope. If this change goes in then it will be difficult to refuse PRs from other projects that want to extend classes in other sealed hierarchies.

Thank you @AlanBateman for having a look and your assement.  I understand, we'll try to find another way 🙂

-------------

PR: https://git.openjdk.org/jdk/pull/11610