Refinements for sealed types
Brian Goetz
brian.goetz at oracle.com
Mon Aug 19 22:58:23 UTC 2019
I was suggesting that a class:
sealed class X { }
with no permitted subtypes would be _both_ ACC_FINAL *and* have an empty
sealing attribute. The rationale would be:
- Reflects intuition that sealed-with-no-permitted-subtypes really
means final, but
- Allows reflection to distinguish between the two.
Maybe the reflection behavior isn't important, at which point we just
drop the latter.
On 8/19/2019 6:52 PM, Alex Buckley wrote:
> On 8/19/2019 3:22 PM, Brian Goetz wrote:
>> I don't have a strong opinion on whether "sealed but no permitted
>> subtypes" is a habitable space separate from "final", but I'm fine to
>> say "that means final" for most purposes. Not sure what reflection
>> should say; is it OK for a type that is clearly sealed in its
>> declaration to report back as "not sealed, but final?" Or does
>> that mean it is both sealed _and_ final (an empty PermittedSubtypes
>> attribute, plus an ACC_FINAL)?
>
> Are you referring here to a source declaration such as `sealed interface
> X {}` where, per Vicente, X.class has ACC_FINAL set? I think
> X.class.isSealed() should return true and X.class.isFinal()
> [simplifying for space] should return false. Has there been any
> discussion of reclaiming ACC_SUPER, 0x0020, for ACC_SEALED in v58
> class files? Using an empty attribute to denote sealing is pretty ugly.
>
> Alex
More information about the amber-spec-experts
mailing list