Interfaces used to model elements of the Java programming language. The term "element" in this package is used to refer to program elements, the declared entities that make up a program. Elements include classes, interfaces, methods, constructors, and fields. The interfaces in this package do not model the structure of a program inside a method body; for example, there is no representation of a for loop or try-finally block. Concretely, there is no model of any abstract syntax tree (AST) structure of a Java program. However, the interfaces can model some structures only appearing inside method bodies, such as local variables, anonymous classes, and exception parameters. Therefore, these interfaces can be used by an AST API to model the declarations found in the method bodies of Java compilation units (JLS 7.3).

When used in the context of annotation processing, an accurate model of the element being represented must be returned. As this is a language model, the source code provides the fiducial (reference) representation of the construct in question rather than a representation in an executable output like a class file. Executable output may serve as the basis for creating a modeling element. However, the process of translating source code to executable output may not permit recovering some aspects of the source code representation. For example, annotations with source retention cannot be recovered from class files and class files might not be able to provide source position information. Names of parameters may not be recoverable from class files. The modifiers on an element created from a class file may differ in some cases from an element for the same declaration created from a source file including:

• strictfp on a class or interface
• final on a parameter
• protected, private, and static on classes and interfaces

Some elements which are mandated may not be marked as such when created from class files. Additionally, synthetic constructs in a class file, such as accessor methods used in implementing nested classes and bridge methods used in implementing covariant returns, are translation artifacts strictly outside of this model. However, when operating on class files, it is helpful to be able to operate on such elements, screening them out when appropriate.

During annotation processing, operating on incomplete or erroneous programs is necessary; however, there are fewer guarantees about the nature of the resulting model. If the source code is not syntactically well-formed or has some other irrecoverable error that could not be removed by the generation of new classes or interfaces, a model may or may not be provided as a quality of implementation issue. If a program for a class or interface is syntactically valid but erroneous in some other fashion, any returned model must have no less information than if all the method bodies in the program were replaced by "throw new RuntimeException();". If a program refers to a missing class or interface Xyz, the returned model must contain no less information than if the declaration of class or interface Xyz were assumed to be "class Xyz {}", "interface Xyz {}", "enum Xyz {}", "@interface Xyz {}", or "record Xyz {}". If a program refers to a missing class or interface Xyz<K1, ... ,Kn>, the returned model must contain no less information than if the declaration of Xyz were assumed to be "class Xyz<T1, ... ,Tn> {}" or "interface Xyz<T1, ... ,Tn> {}"

Unless otherwise specified in a particular implementation, the collections returned by methods in this package should be expected to be unmodifiable by the caller and unsafe for concurrent access.

Unless otherwise specified, methods in this package will throw a NullPointerException if given a null argument.