JEP 447 Statements before super() - Preview feature?

Alex Buckley alex.buckley at oracle.com
Mon May 15 18:47:47 UTC 2023


I am certain there are some demons lurking, and I am even more certain 
that we will be surprised by the interactions of language constructs 
within a ctor body that give rise to them.

In fact, I would like to see the JEP spend less time rehearsing JLS 
modifications and more time exploring how tools, analyzers, linters, etc 
will be impacted by ctor bodies that have a prologue. The Risks & 
Assumptions section should be pages long.

And I will pose another question: are there any tricks, idioms, or 
'patterns' that have been necessary in Java code to workaround the 
super()-comes-first rule? I would like the Motivation or Description (or 
both) to complement the currently rather abstract story (about 
superclasses, guarantees, and top-down initialization) with some 
straightforward code samples of what developers had to write before and 
why it was error-prone and why it hurt maintainability.

Now that the JEP is stable as a Candidate, it's legitimate for Archie, 
as owner, to enhance the text in these ways.

Given the likelihood of dotting i's and crossing t's in the design/spec, 
and in the hope that the JEP can get quite a bit richer, I think at 
least one round of preview is the right thing to do.

Alex

On 5/15/2023 10:13 AM, Brian Goetz wrote:
> I agree that this one is at the edge of what we would need to preview, 
> and so I can see going either way here.  Since we've never done a 
> non-preview language feature since the advent of preview, we kind of 
> have to face the problem here and decide not only for this feature, but 
> on guidelines going forward.  So far, we've been following the implicit 
> policy of "all language features go through preview" (I could easily 
> imagine relaxing this to exclude things that are effectively language 
> bugfixes.)
> 
> On the one hand, previewing adds some cost and work.  It means extra 
> code in the compiler, extra tests, and then more work and another JEP to 
> finalize it.  On the other, preview is a valuable mechanism for getting 
> feedback on a feature before being stuck with it forever.
> 
> One notable thing about *this* JEP is that, even when everyone agreed on 
> the scope and the approach, the spec still required a few rounds of 
> iteration to get it right.  That suggests that even given its narrow 
> focus, there are still potentially some demons lurking.
> 
> 
> 
> On 5/15/2023 12:49 PM, Archie Cobbs wrote:
>> The following question came up and needs opinions from this list...
>>
>> JEP 447 Statements before super() is currently not specified as a 
>> preview feature... should it be?
>>
>> On the one hand, language changes are usually previewed first; on the 
>> other hand, this change is fairly simple and straightforward.
>>
>> Thanks,
>> -Archie
>>
>> -- 
>> Archie L. Cobbs
> 


More information about the amber-spec-experts mailing list