[External] : Re: JEP 447 Statements before super() - Preview feature?

[Alex Buckley]

Hi Archie,

On 5/18/2023 10:16 AM, Archie Cobbs wrote:
> On Mon, May 15, 2023 at 1:47 PM Alex Buckley <alex.buckley at oracle.com 
> <mailto: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).

Yes. Also, the Non-Goals are mostly expressed in terms of specs, which 
isn't right since specs are an "implementation detail" of the feature 
... the Non-Goals should focus on what the end user (a developer) will 
see or not see. Finally, almost no-one will be able to figure out what 
this means -- "There are many ways in which the interplay between 
superclass constructors and subclass initialization might be improved" 
-- so please either explain (in a very small space) or remove.

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

A JEP should be a 360-degree explanation of a feature. It's where the 
feature owner acknowledges the _vast_ numbers of people and software who 
are downstream of (in this case) a Java language construct and will be 
affected by the feature. For example, here's a StackOverflow question 
about ctor invocation with >1MM views:

https://stackoverflow.com/questions/285177/how-do-i-call-one-constructor-from-another-in-java/285184#285184

See how all the top answers make a point of noting that 
`super(..)`/`this(..)` must appear first! I'm not saying you should add 
a Risk of "All the answers on StackOverflow will be invalidated." I'm 
saying that millions of lines of code exist because people explicitly 
coded around the restriction you're now removing, so there's a huge 
amount of refactoring that is (a) possible and (b) desirable, so we 
_assume_ that static analyzers and IDEs will promote this refactoring to 
their users. If you don't say this in the JEP, no-one will know it. 
No-one knows as much as you about this feature, so please share :-)

As to JEP 378 (and others), it is unsatisfactory that there's no "Risks 
and Assumptions" section. We try to do better with each JEP and each 
release, but there are _many_ JEPs in flight for 21 so time has been 
limited. Still, JEP 447 is _changing_ a very longstanding and well known 
construct, so is on the hook more than other JEPs for documenting its 
risks and assumptions ... if it says more now, then it'll be setting a 
good example for future JEPs.

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

I'm sorry, I don't know how I missed the "Implementing fail-fast" 
subsection and its siblings. You show three idioms where the restriction 
on code before `super(..)` has little purpose and impedes understanding.

(I'm sure someone will be along soon to tell us that HotSpot will inline 
a static method like `verifyPositive`, but that won't make the code 
review which questions the method's existence go any quicker, and 
reviewers' time is more expensive than machine time.)

I would like to enrich the "Implementing fail-fast" subsection by 
acknowledging the fine idiom of _telescoping constructors_, where 
simpler constructors delegate to richer constructors by using `this(..)` 
to pass default arguments (see https://stackoverflow.com/a/285187). In 
any intermediate constructor of non-zero arity, being able to check the 
arguments before delegation could be useful.

Ironically, this might resurrect a static helper to check `arg1` and 
`arg2`, because the checks can occur in both the intermediate 
constructor(s) and the richest constructor.

(You can imagine the StackOverflow questions that will emerge about how 
much failing-fast to do in the prologue. Brian used to say that 
yesterday's solutions are today's problems ... well, today's solutions 
are tomorrow's StackOverflow questions. The JEP's role is to get out in 
front of the developer community by acknowledging new idioms and, 
ideally, making recommendations. Anything you put in the JEP will be 
eagerly consumed by JLS authors looking to have sample code and 
conventions in non-normative spec text! I hope I'm being clear that 
where the JEP leads, _everyone_ else follows.)

Thank you for the very good work on JEP 447 so far.

Alex