On Fri, 9 Dec 2022 17:40:49 GMT, Alan Bateman <al...@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
