Hi Archie,
On 5/18/2023 10:16 AM, Archie Cobbs wrote:
On Mon, May 15, 2023 at 1:47 PM Alex Buckley <[email protected]
<mailto:[email protected]>> 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
