This specification is not final and is subject to change. Use is subject to license terms.

Sealed Classes

Changes to the Java® Language Specification • Version 17-internal+0-adhoc.gbierman.20210507

This document describes changes to the Java Language Specification as modified by the specification change document Contextual Keywords, to support sealed classes and interfaces, a feature of Java SE 17. See JEP 409 for an overview of the feature.

The changes are the same as those in the second preview of Sealed Classes in Java SE 16, except for minor editorial changes and the following:

A companion specification change document describes the changes needed to the Java Virtual Machine Specification to support sealed classes and interfaces.

Changes are described with respect to existing sections of the JLS. New text is indicated like this and deleted text is indicated like this. Explanation and discussion, as needed, is set aside in grey boxes.

Chapter 3: Lexical Structure

3.8 Identifiers

An identifier is an unlimited-length sequence of Java letters and Java digits, the first of which must be a Java letter.

Identifier:
IdentifierChars but not a Keyword or BooleanLiteral or NullLiteral
IdentifierChars:
JavaLetter {JavaLetterOrDigit}
JavaLetter:
any Unicode character that is a "Java letter"
JavaLetterOrDigit:
any Unicode character that is a "Java letter-or-digit"

A "Java letter" is a character for which the method Character.isJavaIdentifierStart(int) returns true.

A "Java letter-or-digit" is a character for which the method Character.isJavaIdentifierPart(int) returns true.

The "Java letters" include uppercase and lowercase ASCII Latin letters A-Z (\u0041-\u005a), and a-z (\u0061-\u007a), and, for historical reasons, the ASCII dollar sign ($, or \u0024) and underscore (_, or \u005f). The dollar sign should be used only in mechanically generated source code or, rarely, to access pre-existing names on legacy systems. The underscore may be used in identifiers formed of two or more characters, but it cannot be used as a one-character identifier due to being a keyword.

The "Java digits" include the ASCII digits 0-9 (\u0030-\u0039).

Letters and digits may be drawn from the entire Unicode character set, which supports most writing scripts in use in the world today, including the large sets for Chinese, Japanese, and Korean. This allows programmers to use identifiers in their programs that are written in their native languages.

A sequence of input characters does not represent an identifier if (in a particular context) it represents a keyword (3.9), a boolean literal (3.10.3), or the null literal (3.10.8).

Two identifiers are the same only if, after ignoring characters that are ignorable, the identifiers have the same Unicode character for each letter or digit. An ignorable character is a character for which the method Character.isIdentifierIgnorable(int) returns true. Identifiers that have the same external appearance may yet be different.

For example, the identifiers consisting of the single letters LATIN CAPITAL LETTER A (A, \u0041), LATIN SMALL LETTER A (a, \u0061), GREEK CAPITAL LETTER ALPHA (A, \u0391), CYRILLIC SMALL LETTER A (a, \u0430) and MATHEMATICAL BOLD ITALIC SMALL A (a, \ud835\udc82) are all different.

Unicode composite characters are different from their canonical equivalent decomposed characters. For example, a LATIN CAPITAL LETTER A ACUTE (Á, \u00c1) is different from a LATIN CAPITAL LETTER A (A, \u0041) immediately followed by a NON-SPACING ACUTE (´, \u0301) in identifiers. See The Unicode Standard, Section 3.11 "Normalization Forms".

Examples of identifiers are:

In some contexts, to facilitate the recognition of contextual keywords (3.9), the syntactic grammar disallows certain identifiers by defining a production in terms of a subset of identifiers. These subsets are defined as follows:

TypeIdentifier:
Identifier but not var, yield, or record permits, record, sealed, var or yield

A TypeIdentifier is used in certain contexts involving the declaration or use of types. For example, the name of a class must be a TypeIdentifier, so it is illegal to declare a class named var, yield,or record permits, record, sealed, var or yield (8.1).

UnqualifiedMethodIdentifier:
Identifier but not yield

An UnqualifiedMethodIdentifier is used when referencing a method with a single identifier. An invocation of a method named yield must be qualified, to distinguish the invocation from a yield statement.

3.9 Keywords

51 character sequences, formed from ASCII characters, are reserved for use as keywords and cannot be used as identifiers (3.8). Another 12 15 character sequences, also formed from ASCII characters, may be interpreted as keywords, depending on the context in which they appear.

Keyword:
ReservedKeyword
ContextualKeyword
ReservedKeyword:
(one of)
abstract continue for new switch
assert default if package synchronized
boolean do goto private this
break double implements protected throw
byte else import public throws
case enum instanceof return transient
catch extends int short try
char final interface static void
class finally long strictfp volatile
const float native super while
_ (underscore)
ContextualKeyword:
(one of)
exports opens to var
module provides transitive with
open requires uses yield
sealed non-sealed permits

The keywords const and goto are reserved, even though they are not currently used. This may allow a Java compiler to produce better error messages if these C++ keywords incorrectly appear in programs. The keyword _ (underscore) is reserved for possible future use in parameter declarations.

A character sequence matching a contextual keyword is not treated as a keyword if any part of the sequence can be combined with the immediately preceding or following characters to form a different token.

So the character sequence openmodule is interpreted as a single identifier rather than two contextual keywords, even at the start of a ModuleDeclaration. If two keywords are intended, they must be separated by whitespace or a comment.

Any other character sequence matching a contextual keyword is treated as a keyword if and only if it appears in one of the following contexts of the syntactic grammar:

While these rules depend on details of the syntactic grammar, a compiler for the Java Programming Language can implement them without fully parsing the input program. For example, a heuristic could be used to track the contextual state of the tokenizer, as long as the heuristic guarantees that valid uses of contextual keywords are tokenized as keywords, and valid uses of identifiers are tokenized as identifiers. Or the compiler could always tokenize a contextual keyword as an identifier, leaving it to later stages to recognize special uses of these identifiers.

A variety of character sequences are sometimes assumed, incorrectly, to be keywords:

Chapter 5: Conversions and Contexts

5.1 Kinds of Conversion

5.1.6.1 Allowed Narrowing Reference Conversion

A narrowing reference conversion exists from reference type S to reference type T if all of the following are true:

1. S and T are class types, and either |S| <: |T| or |T| <: |S|.

2. S and T are interface types.

3. S is a class type, T is an interface type, and S does not name a final class (8.1.1).

4. S is a class type, T is an interface type, and S names a final class that implements the interface named by T.

5. S is an interface type, T is a class type, and T does not name a final class.

6. S is an interface type, T is a class type, and T names a final class that implements the interface named by S.

  1. Both S and T are class or interface types, and S names a class or interface that is not disjoint from the class or interface named by T.

    The definition of a class or interface being disjoint from another class or interface is given below.

7. 2. S is the class type Object or the interface type java.io.Serializable or Cloneable (the only interfaces implemented by arrays (10.8)), and T is an array type.

8. 3. S is an array type SC[], that is, an array of components of type SC; T is an array type TC[], that is, an array of components of type TC; and a narrowing reference conversion exists from SC to TC.

9. 4. S is a type variable, and a narrowing reference conversion exists from the upper bound of S to T.

10. 5. T is a type variable, and either a widening reference conversion or a narrowing reference conversion exists from S to the upper bound of T.

11. 6. S is an intersection type S1 & ... & Sn, and for all i (1 ≤ i ≤ n), either a widening reference conversion or a narrowing reference conversion exists from Si to T.

12. 7. T is an intersection type T1 & ... & Tn, and for all i (1 ≤ i ≤ n), either a widening reference conversion or a narrowing reference conversion exists from S to Ti.

A class or interface is said to be disjoint from another class or interface if it can be determined statically that they have no instances in common (other than the null value). It is defined as follows:

  1. A class named C is disjoint from an interface named I if it is not the case that C <: I and one of the following cases applies:

    1. C is final.

    2. C is sealed, and all of the permitted direct subclasses of C are disjoint from I.

    3. C is freely extensible (8.1.1.2), and I is sealed, and C is disjoint from all of the permitted direct subclasses and subinterfaces of I.

    Rules (b) and (c) simply unpack the sealed hierarchies; the important case is rule (a). Consider the following declarations:

    interface I {}
final class C {}

    As class C is final and does not implement I, there can be no instances of C that are also an instance of I, so they are disjoint. Hence there is no narrowing reference conversion from C to I.

    In contrast, consider the following declarations:

    interface J {}
class D {}

    Even though class D does not implement J, it is still possible for an instance of D to be an instance of J; for example, if the following declaration has been made (possibly at a later time):

    class E extends D implements J {}

    For this reason D is not disjoint from J, and there is a narrowing reference conversion from D to J.

  2. An interface named I is disjoint from a class named C if C is disjoint from I.

  3. A class named C is disjoint from another class named D if it is not the case that C <: D, and it is not the case that D <: C.

  4. An interface named I is disjoint from another interface named J if it is not that case that I <: J, and it is not the case that J <: I, and additionally one of the following cases applies:

    1. I is sealed, and all of the permitted direct subclasses and subinterfaces of I are disjoint from J.

    2. J is sealed, and I is disjoint from all the permitted direct subclasses and subinterfaces of J.

    This rule entails that no two extensible interfaces (9.1.1.4) are disjoint.

Chapter 6: Names

6.1 Declarations

A declaration introduces an entity into a program and includes an identifier (3.8) that can be used in a name to refer to this entity. The identifier is constrained to be a TypeIdentifier when the entity being introduced is a class, interface, or type parameter.

A declared entity is one of the following:

Constructors (8.8, [8.10.4]) are also introduced by declarations, but use the name of the class in which they are declared rather than introducing a new name.

The declaration of a generic class or interface (class C<T> ... or interface C<T> ...) introduces both a class named C and a family of types: the raw type C, the parameterized type C<Foo>, the parameterized type C<Bar>, etc.

When a reference to C occurs where genericity is unimportant, identified below as one of the non-generic contexts, the reference to C denotes the class or interface C. In other contexts, the reference to C denotes a type, or part of a type, introduced by C.

The 14 15 non-generic contexts are as follows:

  1. In a uses or provides directive in a module declaration (7.7.1)

  2. In a single-type-import declaration (7.5.1)

  3. To the left of the . in a single-static-import declaration (7.5.3)

  4. To the left of the . in a static-import-on-demand declaration (7.5.4)

  5. In a permits clause of a sealed class or interface declaration (8.1.6, 9.1.4).

5. 6. To the left of the ( in a constructor declaration (8.8)

6. 7. After the @ sign in an annotation (9.7)

7. 8. To the left of .class in a class literal (15.8.2)

8. 9. To the left of .this in a qualified this expression (15.8.4)

9. 10. To the left of .super in a qualified superclass field access expression (15.11.2)

10. 11. To the left of .Identifier or .super.Identifier in a qualified method invocation expression (15.12)

11. 12. To the left of .super:: in a method reference expression (15.13)

12. 13. In a qualified expression name in a postfix expression or a try-with-resources statement (15.14.1, 14.20.3)

13. 14. In a throws clause of a method or constructor (8.4.6, 8.8.5, 9.4)

14. 15. In an exception parameter declaration (14.20)

The first eleven twelve non-generic contexts correspond to the first eleven twelve syntactic contexts for a TypeName in 6.5.1. The twelfth thirteenth non-generic context is where a qualified ExpressionName such as C.x may include a TypeName C to denote static member access. The common use of TypeName in these twelve thirteen contexts is significant: it indicates that these contexts involve a less-than-first-class use of a type. In contrast, the thirteenth fourteenth and fourteenth fifteenth non-generic contexts employ ClassType, indicating that throws and catch clauses use types in a first-class way, in line with, say, field declarations. The characterization of these two contexts as non-generic is due to the fact that an exception type cannot be parameterized (8.1.2).

Note that the ClassType production allows annotations, so it is possible to annotate the use of a type in a throws or catch clause, whereas the TypeName production disallows annotations, so it is not possible to annotate the name of a type in, say, a single-type-import declaration.

...

6.5 Determining the Meaning of a Name

6.5.1 Syntactic Classification of a Name According to Context

A name is syntactically classified as a ModuleName in these contexts:

A name is syntactically classified as a PackageName in these contexts:

A name is syntactically classified as a TypeName in these contexts:

The extraction of a TypeName from the identifiers of a ReferenceType in the 16 contexts above is intended to apply recursively to all sub-terms of the ReferenceType, such as its element type and any type arguments.

For example, suppose a field declaration uses the type p.q.Foo[]. The brackets of the array type are ignored, and the term p.q.Foo is extracted as a dotted sequence of Identifiers to the left of the brackets in an array type, and classified as a TypeName. A later step determines which of p, q, and Foo is a type name or a package name.

As another example, suppose a cast operator uses the type p.q.Foo<? extends String>. The term p.q.Foo is again extracted as a dotted sequence of Identifier terms, this time to the left of the < in a parameterized type, and classified as a TypeName. The term String is extracted as an Identifier in an extends clause of a wildcard type argument of a parameterized type, and classified as a TypeName.

A name is syntactically classified as an ExpressionName in these contexts:

A name is syntactically classified as a MethodName in this context:

A name is syntactically classified as a PackageOrTypeName in these contexts:

A name is syntactically classified as an AmbiguousName in these contexts:

The effect of syntactic classification is to restrict certain kinds of entities to certain parts of expressions:

Chapter 8: Classes

A class declaration defines a new class and describes how it is implemented (8.1).

A top level class (7.6) is a class declared directly in a compilation unit.

A nested class is any class whose declaration occurs within the body of another class or interface declaration. A nested class may be a member class (8.5, 9.5), a local class (14.3), or an anonymous class (15.9.5).

Some kinds of nested class are an inner class (8.1.3), which is a class that can refer to enclosing class instances, local variables, and type variables.

An enum class (8.9) is a class declared with abbreviated syntax that defines a small set of named class instances.

A record class (8.10) is a class declared with abbreviated syntax that defines a simple aggregate of values.

This chapter discusses the common semantics of all classes. Details that are specific to particular kinds of classes are discussed in the sections dedicated to these constructs.

A class may be declared abstract (8.1.1.1) and must be declared abstract if it is incompletely implemented; such a class cannot be instantiated, but can be extended by subclasses.

The degree to which a class can be extended can be explicitly controlled (8.1.1.2). A class may be declared sealed, in which case there is a fixed set of classes that directly extend the sealed class. A class may be declared final (8.1.1.2), in which case it cannot have subclasses.

If a class is declared public, then it can be referred to from code in any package of its module and potentially from code in other modules. Each class except Object is an extension of (that is, a subclass of) a single existing class (8.1.4) and may implement interfaces (8.1.5). Classes may be generic (8.1.2), that is, they may declare type variables whose bindings may differ among different instances of the class.

Class declarations may be decorated with annotations (9.7) just like any other kind of declaration.

The body of a class declares members (fields, methods, classes, and interfaces), instance and static initializers, and constructors (8.1.6). The scope (6.3) of a member (8.2) is the entire body of the declaration of the class to which the member belongs. Field, method, member class, member interface, and constructor declarations may include the access modifiers public, protected, or private (6.6). The members of a class include both declared and inherited members (8.2). Newly declared fields can hide fields declared in a superclass or superinterface. Newly declared member classes and member interfaces can hide member classes and member interfaces declared in a superclass or superinterface. Newly declared methods can hide, implement, or override methods declared in a superclass or superinterface.

Field declarations (8.3) describe class variables, which are incarnated once, and instance variables, which are freshly incarnated for each instance of the class. A field may be declared final (8.3.1.2), in which case it can be assigned to only once. Any field declaration may include an initializer.

Member class declarations (8.5) describe nested classes that are members of the surrounding class. Member classes may be static, in which case they have no access to the instance variables of the surrounding class; or they may be inner classes.

Member interface declarations (8.5) describe nested interfaces that are members of the surrounding class.

Method declarations (8.4) describe code that may be invoked by method invocation expressions (15.12). A class method is invoked relative to the class; an instance method is invoked with respect to some particular object that is an instance of a class. A method whose declaration does not indicate how it is implemented must be declared abstract. A method may be declared final (8.4.3.3), in which case it cannot be hidden or overridden. A method may be implemented by platform-dependent native code (8.4.3.4). A synchronized method (8.4.3.6) automatically locks an object before executing its body and automatically unlocks the object on return, as if by use of a synchronized statement (14.19), thus allowing its activities to be synchronized with those of other threads (17).

Method names may be overloaded (8.4.9).

Instance initializers (8.6) are blocks of executable code that may be used to help initialize an instance when it is created (15.9).

Static initializers (8.7) are blocks of executable code that may be used to help initialize a class.

Constructors (8.8) are similar to methods, but cannot be invoked directly by a method call; they are used to initialize new class instances. Like methods, they may be overloaded (8.8.8).

8.1 Class Declarations

A class declaration specifies a class.

There are three kinds of class declarations: normal class declarations, enum declarations (8.9), and record declarations (8.10).

ClassDeclaration:
NormalClassDeclaration
EnumDeclaration
RecordDeclaration
NormalClassDeclaration:
{ClassModifier} class TypeIdentifier [TypeParameters]
[ClassExtends] [ClassImplements] [ClassPermits]
ClassBody

A class is also implicitly declared by a class instance creation expression (15.9.5) and an enum constant that ends with a class body (8.9.1).

The TypeIdentifier in a class declaration specifies the name of the class.

It is a compile-time error if a class has the same simple name as any of its enclosing classes or interfaces.

The scope and shadowing of a class declaration is specified in 6.3 and 6.4.1.

8.1.1 Class Modifiers

A class declaration may include class modifiers.

ClassModifier:
(one of)
Annotation public protected private
abstract static sealed non-sealed final strictfp

The rules concerning annotation modifiers for a class declaration are specified in 9.7.4 and 9.7.5.

The access modifier public (6.6) pertains only to top level classes (7.6) and member classes (8.5, 9.5), not to local classes (14.3) or anonymous classes (15.9.5).

The access modifiers protected and private pertain only to member classes.

The modifier static pertains only to member classes and local classes.

It is a compile-time error if the same keyword appears more than once as a modifier for a class declaration, or if a class declaration has more than one of the access modifiers public, protected, and private.

It is a compile-time error if a class declaration has more than one of the class modifiers sealed, non-sealed and final.

If two or more (distinct) class modifiers appear in a class declaration, then it is customary, though not required, that they appear in the order consistent with that shown above in the production for ClassModifier.

8.1.1.2 sealed and final Classes

Extensibility of class hierarchies is an important feature of object-oriented programming. However, there are circumstances where explicit control of this extensibility is desirable; in particular, when extensibility is being used not as a mechanism for code inheritance and reuse but, rather, as a way to list the kinds of values in a domain.

A class can be declared sealed when a fixed non-empty set of direct subclasses is desired. A sealed class permits a given set of direct subclasses (8.1.6).

A class can be declared final if its definition is complete and no subclasses are desired or required.

It is a compile-time error if the name of a final class appears in the extends clause (8.1.4) of another class declaration; this implies that a final class cannot have any subclasses.

This rule already appears in 8.1.4.

It is a compile-time error if a class is declared both final and abstract, because the implementation of such a class could never be completed (8.1.1.1).

Because a final class never has any subclasses, the methods of a final class are never overridden (8.4.8.1).

A class that is neither sealed nor final is freely extensible. Most classes are freely extensible by default. A class that directly extends a sealed class (8.1.4) or directly implements a sealed interface (8.1.5) is freely extensible only if it is declared non-sealed.

It is a compile-time error if a class has a sealed direct superclass or a sealed direct superinterface and is not declared final, sealed, or non-sealed.

An enum class can implement a sealed interface, as an enum class is (implicitly) either final or sealed. A record class can also implement a sealed interface as it is implicitly final.

It is a compile-time error if a class has neither a sealed direct superclass nor a sealed direct superinterface but is declared non-sealed.

An effect of the sealed keyword is to force all direct subclasses to explicitly declare whether they are final, sealed, or non-sealed. This avoids accidentally exposing a sealed class hierarchy to unwanted subclassing.

8.1.4 Superclasses

The optional extends clause in a normal class declaration specifies the direct superclass type of the class being declared.

ClassExtends:
extends ClassType

The extends clause must not appear in the definition of the class Object, or a compile-time error occurs, because it is the primordial class and has no direct superclass type.

The ClassType must name an accessible class (6.6), or a compile-time error occurs.

It is a compile-time error if the ClassType names a class that is sealed (8.1.1.2) and the current class is not a permitted direct subclass of that sealed class (8.1.6).

It is a compile-time error if the ClassType names a class that is final, because final classes are not allowed to have subclasses (8.1.1.2).

It is a compile-time error if the ClassType names the class Enum, which can only be extended by an enum class (8.9), or names the class Record, which can only be extended by a record class (8.10).

If the ClassType has type arguments, it must denote a well-formed parameterized type (4.5), and none of the type arguments may be wildcard type arguments, or a compile-time error occurs.

The direct superclass type of a class whose declaration lacks an extends clause is as follows:

The direct superclass of a class is the class named by its direct superclass type. The direct superclass is important because its implementation is used to derive the implementation of the class being declared.

The superclass relationship is the transitive closure of the direct superclass relationship. A class A is a superclass of class C if either of the following is true:

A class is said to be a direct subclass of its direct superclass, and a subclass of each of its superclasses.

Example 8.1.4-1. Direct Superclasses and Subclasses

class Point { int x, y; }
final class ColoredPoint extends Point { int color; }
class Colored3DPoint extends ColoredPoint { int z; }  // error

Here, the relationships are as follows:

The declaration of class Colored3dPoint causes a compile-time error because it attempts to extend the final class ColoredPoint.

Example 8.1.4-2. Superclasses and Subclasses

class Point { int x, y; }
class ColoredPoint extends Point { int color; }
final class Colored3dPoint extends ColoredPoint { int z; }

Here, the relationships are as follows:

A class C directly depends on a class or interface A if A is mentioned in the extends or implements clause of C either as a superclass or superinterface, or as a qualifier in the fully qualified form of a superclass or superinterface name.

A class C depends on a class or interface A if any of the following is true:

It is a compile-time error if a class depends on itself.

If circularly declared classes are detected at run time, as classes are loaded, then a ClassCircularityError is thrown (12.2.1).

Example 8.1.4-3. Class Depends on Itself

class Point extends ColoredPoint { int x, y; }
class ColoredPoint extends Point { int color; }

This program causes a compile-time error because class Point depends on itself.

8.1.5 Superinterfaces

The optional implements clause in a class declaration specifies the direct superinterface types of the class being declared.

ClassImplements:
implements InterfaceTypeList
InterfaceTypeList:
InterfaceType {, InterfaceType}

Each InterfaceType must name an accessible interface (6.6), or a compile-time error occurs.

It is a compile-time error if any InterfaceType names an interface that is sealed (9.1.1.4) and the class being declared is not a permitted direct subclass of the named interface (9.1.4).

If an InterfaceType has type arguments, it must denote a well-formed parameterized type (4.5), and none of the type arguments may be wildcard type arguments, or a compile-time error occurs.

It is a compile-time error if the same interface is named by a direct superinterface type more than once in a single implements clause. This is true even if the interface is named in different ways.

Example 8.1.5-1. Illegal Superinterfaces

class Redundant implements java.lang.Cloneable, Cloneable {
    int x;
}

This program results in a compile-time error because the names java.lang.Cloneable and Cloneable refer to the same interface.

A class whose declaration lacks an implements clause has no direct superinterface types, with one exception: an anonymous class may have a superinterface type (15.9.5).

An interface is a direct superinterface of a class if the interface is named by one of the direct superinterface types of the class.

An interface I is a superinterface of class C if any of the following is true:

A class can have a superinterface in more than one way.

A class is said to directly implement its direct superinterfaces, and to implement all of its superinterfaces.

A class is said to be a direct subclass of its direct superinterfaces, and a subclass of all of its superinterfaces.

A class may not declare a direct superclass type and a direct superinterface type, or two direct superinterface types, which are, or which have supertypes (4.10.2) which are, different parameterizations of the same generic interface (9.1.2), or a parameterization of a generic interface and a raw type naming that same generic interface. In the case of such a conflict, a compile-time error occurs.

This requirement was introduced in order to support translation by type erasure (4.6).

...

8.1.6 Permitted Direct Subclasses

This is a new subsection. The existing subsection 8.1.6 "Class Body and Member Declarations" is renumbered to 8.1.7, and all existing references to it must be renumbered.

The optional permits clause in a class declaration specifies the classes that are permitted to directly extend a sealed class (8.1.1.2).

ClassPermits
permits TypeName {, TypeName }

It is a compile-time error if a class declaration has a permits clause but the declared class is not sealed.

Every TypeName in the permits clause of a class declaration must denote an accessible class (6.6); otherwise a compile-time error occurs.

It is a compile-time error if the same class is specified more than once in a permits clause. This is true even if the class is named in different ways.

The canonical name of a class does not need to be used in a permits clause, but a permits clause can only specify a class once. For example, the following program fails to compile:

package p;
sealed class A permits B, C, p.B {} // Error!
non-sealed class B extends A {}  
non-sealed class C extends A {}

It is a compile-time error if any class specified in the permits clause is not a direct subclass (8.1.4) of the declared class.

If a sealed class C belongs to a named module, then every class specified in the permits clause of the declaration of C must belong to the same module as C; otherwise a compile-time error occurs.

If a sealed class C belongs to an unnamed module, then every class specified in the permits clause of the declaration of C must belong to the same package as C; otherwise a compile-time error occurs.

Sealed class hierarchies are not intended to be declared across different maintenance domains. Modules cannot depend on each other in a circular fashion, yet a sealed class and its direct subclasses need to refer to each other in a circular fashion (in permits and extends clauses, respectively). Necessarily, therefore, a sealed class and its direct subclasses must co-exist in the same module. In an unnamed module, a sealed class and its direct subclasses must belong to the same package.

If a sealed class has a permits clause then its permitted direct subclasses are the classes listed by its permits clause. If a sealed class C lacks a permits clause then its permitted direct subclasses are as follows:

This means that if a sealed class C (that is not an enum class) lacks a permits clause one will be inferred that contains the classes in the same compilation unit that list C as their direct superclass. The requirement of having a canonical name means that no local classes or anonymous classes will be considered.

It is a compile-time error if the declaration of a sealed class C lacks a permits clause and has no permitted direct subclasses.

8.9 Enum Classes

An enum declaration specifies a new enum class, a restricted kind of class that defines a small set of named class instances.

EnumDeclaration:
{ClassModifier} enum TypeIdentifier [ClassImplements] EnumBody

An enum declaration may specify a top level enum class (7.6), a member enum class (8.5, 9.5), or a local enum class (14.3).

The TypeIdentifier in an enum declaration specifies the name of the enum class.

It is a compile-time error if an enum declaration has the modifier abstract, or final, sealed or non-sealed.

An enum declaration is implicitly final unless it contains at least one enum constant that has a class body (8.9.1).

An enum class is either implicitly final or implicitly sealed, as follows:

A nested enum class is implicitly static. That is, every member enum class and local enum class is static. It is permitted for the declaration of a member enum class to redundantly specify the static modifier, but it is not permitted for the declaration of a local enum class (14.3).

It is a compile-time error if the same keyword appears more than once as a modifier for an enum declaration, or if an enum declaration has more than one of the access modifiers public, protected, and private (6.6).

The direct superclass type of an enum class E is Enum<E> (8.1.4).

An enum declaration does not have an extends clause, so it is not possible to explicitly declare a direct superclass type, even Enum<E>.

An enum class has no instances other than those defined by its enum constants. It is a compile-time error to attempt to explicitly instantiate an enum class (15.9.1).

In addition to the compile-time error, three further mechanisms ensure that no instances of an enum class exist beyond those defined by its enum constants:

8.9.1 Enum Constants

The body of an enum declaration may contain enum constants. An enum constant defines an instance of the enum class.

EnumBody:
{ [EnumConstantList] [,] [EnumBodyDeclarations] }
EnumConstantList:
EnumConstant {, EnumConstant}
EnumConstant:
{EnumConstantModifier} Identifier [( [ArgumentList] )] [ClassBody]
EnumConstantModifier:
Annotation

The following production from 15.12 is shown here for convenience:

ArgumentList:
Expression {, Expression}

The rules for annotation modifiers on an enum constant declaration are specified in 9.7.4 and 9.7.5.

The Identifier in a EnumConstant may be used in a name to refer to the enum constant.

The scope and shadowing of an enum constant is specified in 6.3 and 6.4.

An enum constant may be followed by arguments, which are passed to the constructor of the enum when the constant is created during class initialization as described later in this section. The constructor to be invoked is chosen using the normal rules of overload resolution (15.12.2). If the arguments are omitted, an empty argument list is assumed.

The optional class body of an enum constant implicitly defines an anonymous class declaration (15.9.5) that extends the immediately enclosing enum type. The optional class body of an enum constant implicitly defines an anonymous class (15.9.5) that (i) is final, and (ii) extends the immediately enclosing sealed enum class. The class body is governed by the usual rules of anonymous classes; in particular it cannot contain any constructors. Instance methods declared in these class bodies may be invoked outside the enclosing enum class only if they override accessible methods in the enclosing enum class (8.4.8).

Because there is only one instance of each enum constant, it is permitted to use the == operator in place of the equals method when comparing two object references if it is known that at least one of them refers to an enum constant.

The equals method in Enum is a final method that merely invokes super.equals on its argument and returns the result, thus performing an identity comparison.

8.10 Record Classes

A record declaration specifies a new record class, a restricted kind of class that defines a simple aggregate of values.

RecordDeclaration:
{ClassModifier} record TypeIdentifier [TypeParameters] RecordHeader
[ClassImplements] RecordBody

A record declaration may specify a top level record class (7.6), a member record class (8.5, 9.5), or a local record class (14.3).

The TypeIdentifier in a record declaration specifies the name of the record class.

It is a compile-time error if a record declaration has the modifier abstract.

A record class is implicitly final. It is permitted for the declaration of a record class to redundantly specify the final modifier.

It is a compile-time error if a record declaration has the modifier sealed or the modifier non-sealed.

A nested record class is implicitly static. That is, every member record class and local record class is static. It is permitted for the declaration of a member record class to redundantly specify the static modifier, but it is not permitted for the declaration of a local record class (14.3).

It is a compile-time error if the same keyword appears more than once as a modifier for a record declaration, or if a record declaration has more than one of the access modifiers public, protected, and private (6.6).

The direct superclass type of a record class is Record (8.1.4).

A record declaration does not have an extends clause, so it is not possible to explicitly declare a direct superclass type, even Record.

The serialization mechanism treats instances of a record class differently than ordinary serializable or externalizable objects. In particular, a record object is deserialized using the canonical constructor ([8.10.4]).

Chapter 9: Interfaces

An interface declaration defines a new interface that can be implemented by one or more classes. Programs can use interfaces to provide a common supertype for otherwise unrelated classes, and to make it unnecessary for related classes to share a common abstract superclass.

Interfaces have no instance variables, and typically declare one or more abstract methods; otherwise unrelated classes can implement an interface by providing implementations for its abstract methods. Interfaces may not be directly instantiated.

A top level interface (7.6) is an interface declared directly in a compilation unit.

A nested interface is any interface whose declaration occurs within the body of another class or interface declaration. A nested interface may be a member interface (8.5, 9.5) or a local interface (14.3).

An annotation interface (9.6) is an interface declared with distinct syntax, intended to be implemented by reflective representations of annotations (9.7).

This chapter discusses the common semantics of all interfaces. Details that are specific to particular kinds of interfaces are discussed in the sections dedicated to these constructs.

An interface may be declared to be a direct extension of one or more other interfaces, meaning that it inherits all the member classes and interfaces, instance methods, and static fields of the interfaces it extends, except for any members that it may override or hide.

A class may be declared to directly implement one or more interfaces (8.1.5), meaning that any instance of the class implements all the abstract methods specified by the interface or interfaces. A class necessarily implements all the interfaces that its direct superclasses and direct superinterfaces do. This (multiple) interface inheritance allows objects to support (multiple) common behaviors without sharing a superclass.

Unlike a class, an interface cannot be declared final. However, an interface may be declared sealed (9.1.1.4), when there is a fixed set of classes and interfaces that may directly implement or extend the sealed interface.

A variable whose declared type is an interface type may have as its value a reference to any instance of a class which implements the specified interface. It is not sufficient that the class happen to implement all the abstract methods of the interface; the class or one of its superclasses must actually be declared to implement the interface, or else the class is not considered to implement the interface.

9.1 Interface Declarations

An interface declaration specifies an interface. There are two kinds of interface declarations - normal interface declarations and annotation interface declarations (9.6).

InterfaceDeclaration:
NormalInterfaceDeclaration
AnnotationTypeDeclaration
NormalInterfaceDeclaration:
{InterfaceModifier} interface TypeIdentifier [TypeParameters]
[InterfaceExtends] [InterfacePermits]
InterfaceBody

The TypeIdentifier in an interface declaration specifies the name of the interface.

It is a compile-time error if an interface has the same simple name as any of its enclosing classes or interfaces.

The scope and shadowing of an interface declaration is specified in 6.3 and 6.4.

9.1.1 Interface Modifiers

An interface declaration may include interface modifiers.

InterfaceModifier:
(one of)
Annotation public protected private
abstract static sealed non-sealed strictfp

The rules concerning annotation modifiers for an interface declaration are specified in 9.7.4 and 9.7.5.

The access modifier public (6.6) pertains only to top level interfaces (7.6) and member interfaces (8.5, 9.5), not to local interfaces (14.3).

The access modifiers protected and private pertain only to member interfaces.

The modifier static pertains only to member interfaces and local interfaces.

It is a compile-time error if the same keyword appears more than once as a modifier for an interface declaration, or if a interface declaration has more than one of the access modifiers public, protected, and private.

It is a compile-time error if an interface is declared both sealed and non-sealed.

If two or more (distinct) interface modifiers appear in an interface declaration, then it is customary, though not required, that they appear in the order consistent with that shown above in the production for InterfaceModifier.

9.1.1.4 sealed Interfaces

An interface can be declared sealed when there is a known, non-empty, fixed set of direct subclasses and subinterfaces, and no further direct subclasses or subinterfaces are desired or required. A sealed interface permits a given set of direct subclasses and subinterfaces (9.1.4).

An interface that is not sealed is freely extensible. Most interfaces are freely extensible by default. An interface that directly extends a sealed interface (9.1.3) is freely extensible only if it is declared non-sealed.

It is a compile-time error if an interface has a sealed direct superinterface and is not declared sealed or non-sealed.

It is a compile-time error if an interface has no sealed direct superinterface but is declared non-sealed.

9.1.3 Superinterfaces

If an extends clause is provided, then the interface being declared extends each of the specified interface types and therefore inherits the member classes, member interfaces, instance methods, and static fields of each of those interface types.

The specified interface types are the direct superinterface types of the interface being declared.

Any class that implements the declared interface is also considered to implement all the interfaces that this interface extends.

InterfaceExtends:
extends InterfaceTypeList

The following production from 8.1.5 is shown here for convenience:

InterfaceTypeList:
InterfaceType {, InterfaceType}

Each InterfaceType in the extends clause of an interface declaration must name an accessible interface (6.6), or a compile-time error occurs.

It is a compile-time error if any InterfaceType names an interface that is sealed (9.1.1.4) and the current interface is not a permitted direct subinterface of that sealed interface (9.1.4).

If an InterfaceType has type arguments, it must denote a well-formed parameterized type (4.5), and none of the type arguments may be wildcard type arguments, or a compile-time error occurs.

One interface is a direct superinterface of another interface if the first interface is named by one of the direct superinterface types of the second interface.

The superinterface relationship is the transitive closure of the direct superinterface relationship. An interface I is a superinterface of interface K if either of the following is true:

An interface is said to be a direct subinterface of its direct superinterface, and a subinterface of each of its superinterfaces.

While every class is an extension of class Object, there is no single interface of which all interfaces are extensions.

An interface I directly depends on a class or interface A if A is mentioned in the extends clause of I either as a superinterface or as a qualifier in the fully qualified form of a superinterface name.

An interface I depends on a class or interface A if any of the following is true:

It is a compile-time error if an interface depends on itself.

If circularly declared interfaces are detected at run time, as interfaces are loaded, then a ClassCircularityError is thrown (12.2.1).

9.1.4 Permitted Direct Subclasses and Subinterfaces

This is a new subsection. The existing subsection 9.1.4 "Interface Body and Member Declarations" is renumbered to 9.1.5, and all existing references to it must be renumbered.

The optional permits clause in an interface declaration specifies the classes and interfaces that are permitted to directly implement or extend a sealed interface (9.1.1.4).

InterfacePermits
permits TypeName {, TypeName }

It is a compile-time error if an interface declaration has a permits clause but the declared interface is not sealed.

Every TypeName in the permits clause of an interface declaration must denote an accessible class or interface (6.6); otherwise a compile-time error occurs.

It is a compile-time error if a class or interface is specified more than once in a single permits clause. This is true even if the class or interface is named in different ways.

The canonical name of a class or interface does not need to be used in a permits clause, but a permits clause can only specify a class or interface once. For example, the following program fails to compile:

package p;
sealed interface I permits C, D, p.C {} // Error!
non-sealed class C implements I {}
non-sealed class D implements I {}

It is a compile-time error if any class or interface specified in the permits clause is not a direct subclass (8.1.5) or a direct subinterface (9.1.3) of the declared interface.

If a sealed interface I belongs to a named module, then every class or interface specified in the permits clause of the declaration of I must belong to the same module as I; otherwise a compile-time error occurs.

If a sealed interface I belongs to an unnamed module, then every class or interface specified in the permits clause of the declaration of I must belong to the same package as I; otherwise a compile-time error occurs.

Sealed interface hierarchies are not intended to be declared across different maintenance domains. Modules cannot depend on each other in a circular fashion, yet a sealed interface and its direct subclasses and subinterfaces need to refer to each other in a circular fashion (in permits, implements and extends clauses, respectively). Necessarily, therefore, a sealed interface and its direct subclasses and subinterfaces must co-exist in the same module. In an unnamed module, a sealed interface and its direct subclasses and subinterfaces must belong to the same package.

If a sealed interface has a permits clause then its permitted direct subclasses and subinterfaces are the classes and interfaces listed by its permits clause. If a sealed interface I lacks a permits clause then its permitted direct subclasses and subinterfaces are those classes and interfaces declared in the same compilation unit as I (7.3) which have a canonical name (6.7) and whose direct superinterfaces include I.

This means that if a sealed interface I lacks a permits clause one will be inferred that contains the interfaces and classes in the same compilation unit that list I as a direct superinterface. The requirement of having a canonical name means that no local classes, local interfaces, or anonymous classes will be considered.

It is a compile-time error if the declaration of a sealed interface I lacks a permits clause and has no permitted direct subclasses or subinterfaces.

9.6 Annotation Interfaces

An annotation interface declaration specifies an annotation interface, a specialized kind of interface. To distinguish an annotation interface declaration from a normal interface declaration, the keyword interface is preceded by an at sign (@).

AnnotationInterfaceDeclaration:
{InterfaceModifier} @ interface TypeIdentifier AnnotationInterfaceBody

Note that the at sign (@) and the keyword interface are distinct tokens. It is possible to separate them with whitespace, but this is discouraged as a matter of style.

Unless explicitly modified in this section and its subsections, all of the rules that apply to normal interface declarations (9.1) apply to annotation interface declarations.

For example, annotation interface declarations have the same rules for modifiers and scope as normal interface declarations.

It is a compile-time error if an annotation interface declaration has the modifier sealed (9.1.1.4).

An annotation interface declaration may specify a top level interface or a member interface, but not a local interface (14.3).

An annotation interface declaration is not permitted syntactically to appear within a block, by virtue of the LocalClassOrInterfaceDeclaration production in 14.3.

It is a compile-time error if an annotation interface declaration appears directly or indirectly in the body of a local class, local interface, or anonymous class declaration (14.3, 15.9.5).

This rule, together with the syntactic restriction on annotation interface declarations noted above, ensures that an annotation interface always has a canonical name (6.7). Having such a name is important because the purpose of an annotation interface is to be used by annotations in other compilation units. Since a local class or interface does not have a canonical name, an annotation interface declared anywhere within its syntactic body (if that were allowed) would not have a canonical name either.

The following code shows the effect of this rule and the related syntactic restriction:

class C {
    @interface A1 {}  /* Legal: an annotation interface can be a
                         member interface */

    void m() {
        @interface A2 {}  /* Illegal: an annotation interface cannot
                             be a local interface */

        class D {
            @interface A3 {}  /* Illegal: an annotation interface
                                 cannot be specified anywhere within
                                 the body of local class D */

            class E {
                @interface A4 {}
                  /* Illegal: an annotation interface cannot be
                     specified anywhere within the body of local class
                     D, even as a member of a class E nested in D */
            }
        }
    }
}

An annotation interface is never generic (9.1.2).

Unlike a normal interface declaration, an annotation interface declaration cannot declare any type variables, by virtue of the AnnotationTypeDeclaration production.

The direct superinterface type of an annotation interface is always java.lang.annotation.Annotation (9.1.3).

Unlike a normal interface declaration, an annotation interface declaration cannot choose the direct superinterface type via an extends clause, by virtue of the AnnotationTypeDeclaration production.

A consequence of the fact that an annotation interface declaration does not explicitly specify a superinterface type via extends is that a subinterface of an annotation interface is never itself an annotation interface, since the subinterface's declaration necessarily uses an extends clause. Similarly, java.lang.annotation.Annotation is not itself an annotation interface.

An annotation interface inherits several methods from java.lang.annotation.Annotation, including the implicitly declared methods corresponding to the instance methods of Object (9.2), yet these methods do not define elements of the annotation interface (9.6.1).

Because these methods do not define elements of the annotation interface, it is illegal to use them in annotations conforming to the annotation interface (9.7). Without this rule, we could not ensure that elements were of the types representable in annotations, or that accessor methods for them would be available.

9.8 Functional Interfaces

A functional interface is an interface that is not declared sealed and has just one abstract method (aside from the methods of Object), and thus represents a single function contract. This "single" method may take the form of multiple abstract methods with override-equivalent signatures inherited from superinterfaces; in this case, the inherited methods logically represent a single method.

For an interface I that is not declared sealed, let M be the set of abstract methods that are members of I that do not have the same signature as any public instance method of the class Object (4.3.2). Then, I is a functional interface if there exists a method m in M for which both of the following are true:

In addition to the usual process of creating an interface instance by declaring and instantiating a class (15.9), instances of functional interfaces can be created with method reference expressions and lambda expressions (15.13, 15.27).

The definition of functional interface excludes methods in an interface that are also public methods in Object. This is to allow functional treatment of an interface like java.util.Comparator<T> that declares multiple abstract methods of which only one is really "new" - int compare(T,T). The other - boolean equals(Object) - is an explicit declaration of an abstract method that would otherwise be implicitly declared in the interface (9.2) and automatically implemented by every class that implements the interface.

Note that if non-public methods of Object, such as clone(), are explicitly declared in an interface as public, they are not automatically implemented by every class that implements the interface. The implementation inherited from Object is protected while the interface method is public, so the only way to implement the interface would be for a class to override the non-public Object method with a public method.

Example 9.8-1. Functional Interfaces

A simple example of a functional interface is:

interface Runnable {
    void run();
}

The following interface is not functional because it declares nothing which is not already a member of Object:

interface NonFunc {
    boolean equals(Object obj);
}

However, its subinterface can be functional by declaring an abstract method which is not a member of Object:

interface Func extends NonFunc {
    int compare(String o1, String o2);
}

Similarly, the well known interface java.util.Comparator<T> is functional because it has one abstract non-Object method:

interface Comparator<T> {
    boolean equals(Object obj);
    int compare(T o1, T o2);
}

The following interface is not functional because while it only declares one abstract method which is not a member of Object, it declares two abstract methods which are not public members of Object:

interface Foo {
    int m();
    Object clone();
}

Example 9.8-2. Functional Interfaces and Erasure

In the following interface hierarchy, Z is a functional interface because while it inherits two abstract methods which are not members of Object, they have the same signature, so the inherited methods logically represent a single method:

interface X { int m(Iterable<String> arg); }
interface Y { int m(Iterable<String> arg); }
interface Z extends X, Y {}

Similarly, Z is a functional interface in the following interface hierarchy because Y.m is a subsignature of X.m and is return-type-substitutable for X.m:

interface X { Iterable m(Iterable<String> arg); }
interface Y { Iterable<String> m(Iterable arg); }
interface Z extends X, Y {}

The definition of functional interface respects the fact that an interface cannot have two members which are not subsignatures of each other, yet have the same erasure (9.4.1.2). Thus, in the following three interface hierarchies where Z causes a compile-time error, Z is not a functional interface: (because none of its abstract members are subsignatures of all other abstract members)

interface X { int m(Iterable<String> arg); }
interface Y { int m(Iterable<Integer> arg); }
interface Z extends X, Y {}

interface X { int m(Iterable<String> arg, Class c); }
interface Y { int m(Iterable arg, Class<?> c); }
interface Z extends X, Y {}

interface X<T> { void m(T arg); }
interface Y<T> { void m(T arg); }
interface Z<A, B> extends X<A>, Y<B> {}

Similarly, the definition of "functional interface" respects the fact that an interface may only have methods with override-equivalent signatures if one is return-type-substitutable for all the others. Thus, in the following interface hierarchy where Z causes a compile-time error, Z is not a functional interface: (because none of its abstract members are return-type-substitutable for all other abstract members)

interface X { long m(); }
interface Y { int  m(); }
interface Z extends X, Y {}

In the following example, the declarations of Foo<T,N> and Bar are legal: in each, the methods called m are not subsignatures of each other, but do have different erasures. Still, the fact that the methods in each are not subsignatures means Foo<T,N> and Bar are not functional interfaces. However, Baz is a functional interface because the methods it inherits from Foo<Integer,Integer> have the same signature and so logically represent a single method.

interface Foo<T, N extends Number> {
    void m(T arg);
    void m(N arg);
}
interface Bar extends Foo<String, Integer> {}
interface Baz extends Foo<Integer, Integer> {}

Finally, the following examples demonstrate the same rules as above, but with generic methods:

interface Exec { <T> T execute(Action<T> a); }
  // Functional

interface X { <T> T execute(Action<T> a); }
interface Y { <S> S execute(Action<S> a); }
interface Exec extends X, Y {}
  // Functional: signatures are logically "the same"

interface X { <T>   T execute(Action<T> a); }
interface Y { <S,T> S execute(Action<S> a); }
interface Exec extends X, Y {}
  // Error: different signatures, same erasure

Example 9.8-3. Generic Functional Interfaces

Functional interfaces can be generic, such as java.util.function.Predicate<T>. Such a functional interface may be parameterized in a way that produces distinct abstract methods - that is, multiple methods that cannot be legally overridden with a single declaration. For example:

interface I    { Object m(Class c); }
interface J<S> { S m(Class<?> c); }
interface K<T> { T m(Class<?> c); }
interface Functional<S,T> extends I, J<S>, K<T> {}

Functional<S,T> is a functional interface - I.m is return-type-substitutable for J.m and K.m - but the functional interface type Functional<String,Integer> clearly cannot be implemented with a single method. However, other parameterizations of Functional<S,T> which are functional interface types are possible.

The declaration of a functional interface allows a functional interface type to be used in a program. There are four kinds of functional interface type:

In special circumstances, it is useful to treat an intersection type as a functional interface type. Typically, this will look like an intersection of a functional interface type with one or more marker interface types, such as Runnable & java.io.Serializable. Such an intersection can be used in casts (15.16) that force a lambda expression to conform to a certain type. If one of the interface types in the intersection is java.io.Serializable, special run-time support for serialization is triggered (15.27.4).

Chapter 13: Binary Compatibility

13.4 Evolution of Classes

13.4.2 sealed, non-sealed and final Classes

The discussion about final classes has been moved to a new subsection 13.4.2.3.

13.4.2.1 sealed Classes

If a class that was freely extensible (8.1.1.2) is changed to be declared sealed, then an IncompatibleClassChangeError is thrown if a binary of a pre-existing subclass of this class is loaded that is not contained in its permits clause; such a change is not recommended for widely distributed classes.

Changing a class that was declared final to be declared sealed does not break compatibility with pre-existing binaries.

Removing the sealed modifier from a class that does not have a sealed direct superclass or a sealed direct superinterface does not break compatibility with pre-existing binaries.

If a sealed class C did have a sealed direct superclass or a sealed direct superinterface, then simply removing the sealed modifier would mean that C would not compile as every class with a sealed direct superclass or a sealed direct superinterface must be either final, sealed or non-sealed (8.1.1.2).

13.4.2.2 non-sealed Classes

Changing a class that was declared sealed to be declared non-sealed does not break compatibility with pre-existing binaries.

Changing a class that was declared final to be declared non-sealed does not break compatibility with pre-existing binaries.

A non-sealed class C must have a sealed direct superclass or a sealed direct superinterface (8.1.1.2). Simply removing the non-sealed modifier from C would mean that C would not compile as every class with a sealed direct superclass or a sealed direct superinterface must be either final, sealed or non-sealed (8.1.1.2).

13.4.2.3 final Classes

If a class that was not declared final is changed to be declared final, then a VerifyError is thrown if a binary of a pre-existing subclass of this class is loaded, because final classes can have no subclasses; such a change is not recommended for widely distributed classes.

Changing a class that is declared final to no longer be declared final does not break compatibility with pre-existing binaries.

Removing the final modifier from a class that does not have a sealed direct superclass or a sealed direct superinterface does not break compatibility with pre-existing binaries.

If a final class C did have a sealed direct superclass or a sealed direct superinterface, then simply removing the final modifier would mean that C would not compile as every class with a sealed direct superclass or a sealed direct superinterface must be either final, sealed or non-sealed (8.1.1.2).

13.4.5 Permitted Direct Subclasses

Adding a class to the set of permitted direct subclasses of a sealed class (8.1.6) will not break compatibility with pre-existing binaries.

If a class is removed from the set of permitted direct subclasses of a sealed class (8.1.6) then an IncompatibleClassChangeError is thrown if the pre-existing binary of the removed class is loaded.

13.5 Evolution of Interfaces

Existing section 13.5.2 is renumbered as 13.5.3. Existing sections 13.5.3 - 13.5.7 are renumbered as 13.5.5 - 13.5.9.

13.5.2 sealed and non-sealed Interfaces

If an interface that was freely extensible (9.1.1.4) is changed to be declared sealed, then an IncompatibleClassChangeError is thrown if a binary of a pre-existing subclass or subinterface of this interface is loaded that is not specified in its permits clause; such a change is not recommended for widely distributed classes.

Removing the sealed modifier from an interface that does not have a sealed direct superinterface does not break compatibility with pre-existing binaries.

If a sealed interface I did have a sealed direct superinterface, then simply removing the sealed modifier from I would mean that I would not compile as every interface with a sealed direct superinterface must be sealed or non-sealed (9.1.1.4).

Changing an interface that is declared sealed to be declared non-sealed does not break compatibility with pre-existing binaries.

A non-sealed interface I must have a sealed direct superinterface (9.1.1.4). Simply removing the non-sealed modifier from I would mean that I would not compile as every interface with a sealed direct superinterface must be sealed or non-sealed (9.1.1.4).

13.5.4 Permitted Direct Subclasses and Subinterfaces

Adding a class or interface to the set of permitted direct subclasses or subinterfaces, respectively, of a sealed interface (9.1.4) will not break compatibility with pre-existing binaries.

If a class or interface is removed from the set of permitted direct subclasses or subinterfaces of a sealed interface (9.1.4) then an IncompatibleClassChangeError is thrown if the pre-existing binary of the removed class or interface is loaded.

Chapter 14: Blocks and Statements

14.3 Local Class and Interface Declarations

A local class is a nested class (8) whose declaration is immediately contained by a block (14.2).

A local interface is a nested interface (9) whose declaration is immediately contained by a block.

LocalClassOrInterfaceDeclaration:
ClassDeclaration
NormalInterfaceDeclaration

The following productions are shown here for convenience:

ClassDeclaration:
NormalClassDeclaration
EnumDeclaration
RecordDeclaration
NormalClassDeclaration:
{ClassModifier} class TypeIdentifier [TypeParameters]
[ClassExtends] [ClassImplements] [ClassPermits]
ClassBody
EnumDeclaration:
{ClassModifier} enum TypeIdentifier [ClassImplements] EnumBody
NormalInterfaceDeclaration:
{InterfaceModifier} interface TypeIdentifier [TypeParameters]
[InterfaceExtends] [InterfacePermits]
InterfaceBody

Local class and interface declarations may be intermixed freely with statements (including local variable declaration statements) in the containing block.

It is a compile-time error if a local class or interface declaration has any of the access modifiers public, protected, or private (6.6).

It is a compile-time error if a local class or interface declaration has the modifier static (8.1.1), sealed or non-sealed (8.1.1.2).

A local class may be a normal class (8.1), an enum class (8.9), or a record class (8.10). Every local normal class is an inner class (8.1.3). Every local enum class and local record class is implicitly static (8.1.1.4), and therefore not an inner class.

A local interface may be a normal interface (9.1), but not an annotation interface (9.6). Every local interface is implicitly static (9.1.1.3).

Like an anonymous class (15.9.5), a local class or interface is not a member of any package, class, or interface (7.1, 8.5). Unlike an anonymous class, a local class or interface has a simple name (6.2, 6.7).

It is a compile-time error if the direct superclass or direct superinterface of a local class is sealed (8.1.1.2).

It is a compile-time error if the direct superinterface of a local interface is sealed (9.1.1.4).

The scope and shadowing of a local class or interface declaration is specified in 6.3 and 6.4.

Example 14.3-1. Local Class Declarations

Here is an example that illustrates several aspects of the rules given above:

class Global {
    class Cyclic {}

    void foo() {
        new Cyclic(); // create a Global.Cyclic
        class Cyclic extends Cyclic {} // circular definition

        {
            class Local {}
            {
                class Local {} // compile-time error
            }
            class Local {} // compile-time error
            class AnotherLocal {
                void bar() {
                    class Local {} // ok
                }
            }
        }
        class Local {} // ok, not in scope of prior Local
    }
}

The first statement of method foo creates an instance of the member class Global.Cyclic rather than an instance of the local class Cyclic, because the statement appears prior to the scope of the local class declaration.

The fact that the scope of a local class declaration encompasses its whole declaration (not only its body) means that the definition of the local class Cyclic is indeed cyclic because it extends itself rather than Global.Cyclic. Consequently, the declaration of the local class Cyclic is rejected at compile time.

Since local class names cannot be redeclared within the same method (or constructor or initializer, as the case may be), the second and third declarations of Local result in compile-time errors. However, Local can be redeclared in the context of another, more deeply nested, class such as AnotherLocal.

The final declaration of Local is legal, since it occurs outside the scope of any prior declaration of Local.

Chapter 15: Expressions

15.9 Class Instance Creation Expressions

15.9.1 Determining the Class being Instantiated

If ClassOrInterfaceTypeToInstantiate ends with TypeArguments (rather than <>), then ClassOrInterfaceTypeToInstantiate must denote a well-formed parameterized type (4.5), or a compile-time error occurs.

If ClassOrInterfaceTypeToInstantiate ends with <>, but the class or interface denoted by the Identifier in ClassOrInterfaceTypeToInstantiate is not generic, then a compile-time error occurs.

If the class instance creation expression ends in a class body, then the class being instantiated is an anonymous class. Then:

If a class instance creation expression does not declare an anonymous class, then:

15.9.5 Anonymous Class Declarations

An anonymous class is implicitly declared by a class instance creation expression or by an enum constant that ends with a class body (8.9.1).

An anonymous class is never abstract (8.1.1.1).

An anonymous class is never sealed (8.1.1.2), and thus has no permitted direct subclasses (8.1.6).

An anonymous class declared by a class instance creation expression is never final (8.1.1.2).

An anonymous class declared by an enum constant is always final.

An anonymous class being non-final is relevant in casting, in particular the narrowing reference conversion allowed for the cast operator (5.5). On the other hand, it is not relevant to subclassing, because it is impossible to declare a subclass of an anonymous class (an anonymous class cannot be named by an extends clause) despite the anonymous class being non-final.

An anonymous class is always an inner class (8.1.3).

Like a local class or interface (14.3), an anonymous class is not a member of any package, class, or interface (7.1, 8.5).

The direct superclass type or direct superinterface type of an anonymous class declared by a class instance creation expression is given by the expression (15.9.1), with type arguments inferred as necessary while choosing a constructor (15.9.3). If a direct superinterface type is given, the direct superclass type is Object.

The direct superclass type of an anonymous class declared by an enum constant is the type of the declaring enum class.

The ClassBody of the class instance creation expression or enum constant declares fields (8.3), methods (8.4), member classes (8.5), member interfaces (9.1.1.3), instance initializers (8.6), and static initializers (8.7) of the anonymous class. The constructor of an anonymous class is always implicit (15.9.5.1).

If a class instance creation expression with a ClassBody uses a diamond (<>) for the type arguments of the class to be instantiated, then for all non-private methods declared in the ClassBody, it is as if the method declaration is annotated with @Override (9.6.4.4).

When <> is used, the inferred type arguments may not be as anticipated by the programmer. Consequently, the supertype of the anonymous class may not be as anticipated, and methods declared in the anonymous class may not override supertype methods as intended. Treating such methods as if annotated with @Override (if they are not explicitly annotated with @Override) helps avoid silently incorrect programs.