help with changes to hotspot runtime to implement sealed types

Vicente Romero vicente.romero at
Wed Dec 12 01:53:34 UTC 2018

Hi HS runtime,

I'm working on the implementation of sealed types one of the projects 
under the Amber umbrella. A sealed type is one that can only be subtyped 
by a set of classes declared by the sealed type in Java:

final class Sealed permits Sub {}
    class Sub extends Sealed {}

Both Sealed and Sub can coexist in the same compilation unit, package or 
module. The class file for Sealed have an attribute named 
PermittedSubtypes that contains a list with the, well, permitted 
subtypes. In the case of the example it will be Sub only. On top of that 
class Sealed will be final. So when loading / parsing class file for 
Sub, we need to check, given that its supertype is final, if Sub is 
listed as one of the permitted subtypes of Sealed or fail in other case. 
And here is when I'm finding a roadblock. Currently the VM doesn't allow 
any class to subtype a final class and this is checked at:


so I removed the code that was doing this check at `ClassFileParser` and 
created a separate method to do the checking at InstanceKlass with the 
idea of enforcing the check after the class file was parsed and the 
given class loaded. But regardless of my intents I always get a SOE. The 
SOE happens when the subclass ask the super class if the subclass is 
listed as one of its permitted subtypes. To answer this, the superclass 
tries to load the subclass so I have a deadlock that I suspect could be 
hard to solve, if possible. Please see attached what I have done so far. 
Any ideas?


PD, the code runs with no error with the slowdebug configuration
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sealed.runtime.diff
Type: text/x-patch
Size: 21593 bytes
Desc: not available
URL: <>

More information about the amber-dev mailing list