Draft Spec for Statements before Super() (JEP 447)

Alex Buckley alex.buckley at oracle.com
Thu Apr 20 22:42:21 UTC 2023

Hi Gavin, a few comments on a super draft for a super() feature.

On 4/20/2023 2:19 PM, Gavin Bierman wrote:
> The first draft of the spec change document for the feature Statements 
> before super() [1] is now available at:
> https://cr.openjdk.org/~gbierman/jep447/latest/

1. The decision to sever constructor bodies from "static context" is 
righteous. As the edit in 8.1.3 implies, a static context is properly 
defined to involve _no_ current instance, versus the traditional 
definition of there's-a-current-instance-but-you-can't-refer-to-it. It 
is right to introduce a new kind of context for (some of) a constructor 
body, where uniquely there's-a-current-instance-but-you-can't-refer-to-it.

2. For the new kind of context, I recommend "pre-construction context" 
instead of "pre-initialization context". Initialization is what happens 
to a class prior to any constructors being run. The last paragraph of 
15.9 is keen on a class being "instantiated" but I think most people 
would trip over "pre-instantiation context" and would thank you for the 
plainspoken "pre-construction context".

3. The new kind of context is introduced as a _dynamic_ artifact -- "... 
a pre-initialization context *of the current object*" -- but it's 
sweeping out a lexical space. Even the dynamic story about new instances 
in 12.5 doesn't mention the pre-initialization context *of the new 
instance*. Wouldn't the following pattern work throughout:

    "It is a compile-time error if a this expression occurs in a static 
context (8.1.3) or in ~a~ +the+ pre-initialization context of ~the 
associated instance~ +a constructor body+ ("

4. In, you mention "An explicit constructor invocation 
*statement* ...". It would be worth noting in 8.8.7 that an explicit 
constructor invocation is not a statement by the technical meaning of 
14.5, yet shares most of the characteristics of statements such as (i) 
having normal and abrupt completion, and (ii) potentially being 
unreachable by 14.22. (You ban `return` in the prologue, but see below 
for a notional ctor body that I'm certain javac would sensibly reject 
for an unreachable `super();` "statement".)

P: {
     System.out.println("ctor started");
     break P;
System.out.println("ctor finished");


More information about the amber-spec-experts mailing list