The Java programming language is a relatively high-level language, in that details of the machine representation are not available through the language. It includes automatic storage management, typically using a garbage collector, to avoid the safety problems of explicit deallocation (as in C's free or C++'s delete). High-performance garbage-collected implementations can have bounded pauses to support systems programming and real-time applications. The language does not include any unsafe constructs, such as array accesses without index checking, since such unsafe constructs would cause a program to behave in an unspecified way.

1.1. Organization of the Specification

Throughout this specification, we refer to classes and interfaces drawn from the Java SE Platform API. Whenever we refer to a class or interface (other than those declared in an example) using a single identifier N, the intended reference is to the class or interface named N in the package java.lang. We use the canonical name (§6.7) for classes or interfaces from packages other than java.lang.

Non-normative text, designed to clarify the normative text of this specification, is given in smaller, indented text.

Preview language features are specified in standalone documents that indicate changes ("diffs") to The Java® Language Specification for that release. The specifications of preview language features are incorporated into The Java® Language Specification by reference, and made a part thereof, if and only if preview features are enabled at compile time.

Preview APIs are specified within the Java SE API Specification for that release.

Stroustrup, Bjarne. The C++ Programming Language, 2nd ed. Addison-Wesley, Reading, Massachusetts, 1991, reprinted with corrections January 1994, ISBN 0-201-53992-6.

try {

throw new FileNotFoundException();

} catch (IOException ioe) {

// and any subtype.

}

} catch (IOException ioe) {

// Legal, but compilers are encouraged to give

// warnings as of Java SE 7, because all subtypes of

// already been caught by the prior catch clause.

}

// that m "can throw" a subtype or supertype of

// IOException (e.g. Exception).

} catch (FileNotFoundException fnfe) {

// might be FileNotFoundException.

} catch (IOException ioe) {

// Legal, because the dynamic type of the exception

The Java Virtual Machine starts execution by invoking the method main of some specified class or interface, passing it a single argument which is an array of strings. In the examples in this specification, this first class is typically called Test.

The manner in which the initial class or interface is specified to the Java Virtual Machine is beyond the scope of this specification, but it is typical, in host environments that use command lines, for the fully qualified name of the class or interface to be specified as a command line argument and for following command line arguments to be used as strings to be provided as the argument to the method main.

Loading refers to the process of finding the binary form of a class or interface with a particular name, perhaps by computing it on the fly, but more typically by retrieving a binary representation previously computed from source code by a Java compiler, and constructing, from that binary form, a Class object to represent the class or interface (§1.4).

12.2.1. The Loading Process

A malicious class loader could violate these properties. However, it could not undermine the security of the type system, because the Java Virtual Machine guards against this.

12.3. Linking of Classes and Interfaces

Linking is the process of taking a binary form of a class or interface and combining it into the run-time state of the Java Virtual Machine, so that it can be executed. A class or interface is always loaded before it is linked.

Three different activities are involved in linking: verification, preparation, and resolution of symbolic references.

12.6. Finalization of Class Instances

The class Object has a protected method called finalize; this method can be overridden by other classes. The particular definition of finalize that can be invoked for an object is called the finalizer of that object. Before the storage for an object is reclaimed by the garbage collector, the Java Virtual Machine will invoke the finalizer of that object.

/* finalize outer Foo object */

}

}

13.1. The Form of a Binary

A class file corresponding to a class or interface declaration must have certain properties. A number of these properties are specifically chosen to support source code transformations that preserve binary compatibility. The required properties are:

Suppose that the following test program:

class Super extends Hyper { char s = 's'; }

class Test extends Super {

public static void printH(Hyper h) {

Test t = new Test();

t.print();

}

}

}

var a = 1; // a has type 'int'

var b = java.util.List.of(1, 2); // b has type 'List<Integer>'

// (see JLS 15.12.2.6)

var d = new Object() {}; // d has the type of the anonymous class

var e = (CharSequence & Comparable<String>) "x";

while (n-- != 0) {

if (v1[j++] != v2[k++])

continue i;

return i - offset;

}

return -1;

public class Foo {

public static void main(String[] args) {

// Will execute after Baz is initialized.

}

}

class Bar {

static {

// Will execute before Baz is initialized!

}

}

class Baz extends Bar {

static void testAsserts() {

boolean enabled = false;

assert enabled = true;

}

}

Object obj = ...;

... // Error! Is i or b initialized?

}

Even if only one of the case patterns declares a pattern variable, it would still not be clear whether the variable was initialized or not; for example:

Object obj = ...;

... // Error! Is i initialized?

}

The following does not result in a compile-time error:

Object obj = ...;

... // Matches both an Integer and a Boolean

}

case Integer _, String _ -> // Error - dominated!

System.out.println("An Integer or a String");

...

A case label with a case constant c is dominated if one of the following holds:

case H -> 2; // No default required!

};

}

The type T names an abstract sealed class or sealed interface C and for every permitted direct subclass or subinterface D of C, one of the following two conditions holds:

A default label is permitted, but not required, in the case where the switch block exhausts all the permitted direct subclasses and subinterfaces of an abstract sealed class or sealed interface. For example:

sealed interface I permits A, B, C {}

final class A implements I {}

howMany(3);

howManyAgain(1);

howManyAgain(2);

}

}