Contents | Prev | Next | Inner Classes Specification

# Other changes in the Java 1.1 language

The Java 1.1 language includes four additional extensions which fill small holes in the language, and make certain kinds of APIs easier to use.

## Instance initializers

The static initializer syntax is extended to support instance initialization also:

ClassBodyDeclaration:
Block
Initialization code introduced without the `static` keyword is executed by every constructor, just after the superclass constructor is called, in textual order along with any instance variable initializations.

An instance initializer may not return, nor throw a checked exception, unless that exception is explicitly declared in the `throws` clause of each constructor. An instance initializer in an anonymous class can throw any exceptions.

Instance initializers are useful when instance variables (including blank finals) must be initialized by code which must catch exceptions, or perform other kinds of control flow which cannot be expressed in a single initializer expression. Instance initializers are required if an anonymous class is to initialize itself, since an anonymous class cannot declare any constructors.

## Anonymous array expressions

The array allocation syntax is extended to support initialization of the elements of anonymous arrays. Just as a named array can be initialized by a brace- enclosed list of element expressions, an array creation expression can now be followed by such a brace-enclosed list. In both cases, the array type is not allowed to include any dimension expressions; the dimension is computed by counting the number of element expressions. Here is the new syntax:

ArrayCreationExpression:
`new` Type Dims ArrayInitializer
The equivalence of the following two statements illustrates the new syntax:

                T v[] = {a};
                T v[] = new T[] {a};

## Class literals

PrimaryNoNewArray:
...
Type `.` `class
` `void` `.` `class`
A class literal is an expression consisting of the name of a class, interface, array, or primitive type followed by a ``.`' and the token `class`. It evaluates to an object of type `Class`, the class object for the named type (or for void).

For reference types, a class literal is equivalent to a call to `Class.forName` with the appropriate string, except that it does not raise any checked exceptions. (Its efficiency is likely to be comparable to that of a field access, rather than a method call.) The class literal of a reference type can raise `NoClassDefFoundError`, in much the same way that a class variable reference can raise that error if the variable's class is not available.

The class literal of a primitive type or void is equivalent to a static variable reference to a pre-installed primitive type descriptor, according to this table:

            boolean.class   ==   Boolean.TYPE
            char.class      ==   Character.TYPE
            byte.class      ==   Byte.TYPE
            short.class     ==   Short.TYPE
            int.class       ==   Integer.TYPE
            long.class      ==   Long.TYPE
            float.class     ==   Float.TYPE
            double.class    ==   Double.TYPE
            void.class      ==   Void.TYPE

Java APIs which require class objects as method arguments are much easier to use when the class literal syntax is available. Note that the compiler is responsible for taking into account the ambient `package` and `import` statements when processing the TypeName of a class literal.

The older usage of `Class.forName` requires the programmer to figure out the desired package prefix and write it in a class name string. The difficulty of getting the string spelled right becomes greater in the presence of inner classes, since their names (as processed by `Class.forName`) are encoded with ``$`' characters instead of dots.

Note that a class literal never contains an expression, only a type name.

## Blank finals and final local variables

A blank final is `final` variable declaration (of any kind) which lacks an initializer. A blank final must be assigned an initial value, at most once.

The definite assignment rules are extended to record variables which are "definitely unassigned," and an assignment to a blank final is prohibited unless the final is definitely unassigned before the assignment statement. Subsequently, it is definitely assigned, and, being a `final`, it cannot be re- assigned along the same execution path.

The definite unassignment rules take into account back-branches of loops, so that a variable occurrence in a loop body may not be definitely unassigned if the loop makes an assignment which can reach the occurrence via a back- branch. The definite assignment checks work as if the first iteration of the loop had been unrolled into an `if` statement.

A blank final class variable must be definitely assigned by a `static` initializer (in the same class). This is the only context where class variables are checked for definite assignment.

A blank final instance variable must be definitely assigned by a non-`static` initializer, or else by every constructor. These are the only contexts in which definite assignment checking is done on instance variables. Within these contexts, an assignment to `this.`V is recognized as performing an assignment to the name V for purposes of definite assignment checking.

Local variables and parameters of all sorts can now be declared `final`:

LocalVariableDeclaration:
ModifiersOpt Type VariableDeclarators
FormalParameter:
ModifiersOpt Type VariableDeclaratorId
Such a variable is subject to the usual definite assignment rules governing local variables. In addition, it cannot be assigned to, except for initialization.

A method parameter or catch formal parameter may be declared `final`. This has no effect on the method signature or the caught exception type. Within the body of the method or catch, the parameter may not be assigned to.

The `final` declaration modifier may be used to make local variables and parameters available to inner classes.

Contents | Prev | Next

Inner Classes Specification (HTML generated by dkramer on March 15, 1997)
Copyright © 1996, 1997 Sun Microsystems, Inc. All rights reserved
Please send any comments or corrections to john.rose@eng.sun.com