Summary
-------

In constructors in the Java programming language, allow statements that do not
read the fields of the instance being created to appear before an explicit
constructor invocation.

Problem
-------

The Java language disallows any statements in constructors prior to an explicit
constructor invocation as a way of preventing access to the current instance
prior to superclass construction. This ensures that object construction proceeds
in an orderly fashion "from the top down".

However, this rule prevents a variety of common patterns that are available to
regular methods. For example:

*   "Fail fast" validation of constructor parameters as the first order of
    business
*   Creating an object to pass to the superclass constructor in two different
    parameter positions
*   Complex preparation and/or selection of superclass constructor parameters
*   Initialization of superclass fields by a subclass

This rule is more restrictive than it needs to be. All of the existing semantic
and safety guarantees relating to constructors are still preserved if code can
appear prior to an explicit constructor invocation as long as two criteria are
met:

*   The code does not refer to the current `this` instance (either explicitly or
    implicitly), except in a field access that appears on the left-hand side of
    a simple assignment.
  
*   There are no `return` statements

Note that the first item is not new; except for the carve-out for simple
assignments, it is exactly the same criterion that applies today to
subexpressions of an explicit constructor invocation.

Solution
--------

The grammar of a constructor body is changed from:

```
ConstructorBody:
    { [ExplicitConstructorInvocation] [BlockStatements] } ;
```
to:
```
ConstructorBody:
    { [BlockStatements] } ;
    { [BlockStatements] ExplicitConstructorInvocation [BlockStatements] } ;
```


The Java Language Specification classifies code that appears in the argument
list of an explicit constructor invocation as being in a _static context_. This
means that the arguments to the explicit constructor invocation are treated as
if they were in a static method; in other words, as if no instance is available.
The technical restrictions of a static context are stronger than necessary,
however, and they prevent code that is useful and safe from appearing as
constructor arguments. Moreover, the `javac` compiler has enforced more relaxed
conditions, which have been exploited by many developers.


For example, subexpressions of an explicit constructor invocation in a
constructor body of an inner class commonly refer to the outer instance; for
example:

```
public class MyClass {
    public void doSomething() {
        // ...
    }
    public class MyThread extends Thread {
        public MyThread() {
            super(MyClass.this::doSomething);
        }
    }
}
```

To fix the JLS, rather than revise the concept of a static context, we define a
new, strictly weaker concept of an _early construction context_ to cover both
the arguments to an explicit constructor invocation and any statements that
appear before it. The rules for code in an early construction context are
similar to the rules for code in an instance method, except for one restriction:
in an early construction context, code must not read the fields of the instance
under construction.

On `amber-dev` there was a good deal of discussion regarding the how far to expand
the rules. The eventual consensus was to take a conservative approach, so the
above set of changes represents a minimal choice. Two other options that were
considered were:

1.  Allow multiple explicit constructor invocations, and use DA/DU analysis to
    ensure exactly one call is ever executed
2.  Allow explicit constructor invocations within `try` blocks, with the
    requirement that if any exceptions are caught the constructor must complete
    abruptly.

Aside: The first condition would not require any change to the JVMS, whereas the
second would require a (straightforward) change.

It should also be noted that this feature does not change the semantics of any
existing code.

## History

Following the third preview there have been no further issues, so we feel this feature is ready to be finalised. 

## Specification

The JLS changes are identical to those in the third preview apart from
minor bugs that have been noticed during the preview period. A draft is attached.