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

Reply via email to