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