JEP 447 Statements before super() - Preview feature?

[Archie Cobbs]

Hi Alex,

On Mon, May 15, 2023 at 1:47 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> In fact, I would like to see the JEP spend less time rehearsing JLS
> modifications


We are planning to remove all the JLS specification changes - they belong
in the CSR instead (this distinction was not clear to me at first).

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.
>

Can you elaborate on why you think this is needed?

Of course, it's obviously true that any change to the language is going to
affect analyzers, linters, and other such tools. So the question is whether
this needs to be explicitly noted.

I was gauging this based on what I've seen in other JEP's. For example, JEP
378 Text Blocks <https://openjdk.org/jeps/378> includes no such discussion,
yet that change has a clear impact on such tools.

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.
>

This was the goal of the section starting with "the current rule causes
idioms commonly used within normal methods to be either difficult or
impossible to use within constructors. Below are a few examples." Let me
know if you think these examples are unclear.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230518/d046d520/attachment.htm>