<div dir="ltr">Hi,<div><br></div><div>I believe that the following is a known request. Consider the class</div><div><br></div><div>class Boat {</div><div><br></div><div>    final int sails;</div><div><br></div><div>    Boat(Type type) {</div><div>        switch (type) {</div><div>            case ENGINE -> 

sails = 0;</div><div>            case SAIL -> sails = 2;<br></div><div>            default -> sails = 1;</div><div>        }</div><div>    }</div><div>}</div><div><br></div><div>This is fine (and yes, can be written better). However, if I try to extract the constructor body into a private method, I get a compilation error that the final field has not been assigned. Understandable at this point.</div><div><br></div><div>In some classes that are more complex than my contrived example, the constructor's body is divided into steps ('createSails', 'createAnchor'...) that assign final fields. The current situation forces all of the code to appear in one big chunk in the constructor, instead of being able to divide the work into methods, as we usually like to do with methods. There is a known clear readability and maintenance benefit here.</div><div><br></div><div>I'm aware that there is a school of thought saying that the constructor should only do simple things, and all the preparation should be done before instantiating the class. Basically, calling createSails() etc. first and then sending the results to the constructor to just do  checks and assignments. I don't always subscribe to this approach, especially since it exposes implementation details (what if the return type of createSails() should be internal to Boat only?).</div><div><br></div><div>I remember some discussion for "nested methods": allowing methods (and constructors) to contain other methods; I assume that that would be one way to solve it. One can also use simple scopes (`{ ... }`) to divide the method/constructor. However, I would like you to consider the following solution.</div><div>If the method satisfies these conditions:</div><div>1. It is private (and thus final)</div><div>2. It is called only from the/a constructor</div><div>3. It is called only once</div><div>then it may assign final fields. The last condition might not be strictly necessary because there is already a check if the final field has been assigned already. These conditions can be applied recursively, checking if the call originates in the constructor and allowing to further divide the constructors into sub-steps, but I'm willing to wait with this addition.</div><div><br></div><div>I think that this can be checked rather easily by static analysis. I CC'd Archie who has done similar work in JEP 447 (static analysis to remove unnecessary restrictions in the constructor) to weigh in. I say "rather easily" because these conditions don't require looking at the class hierarchy - they are limited to the inspected class only.</div><div><br></div><div>Thoughts?</div><div><br></div><div>- Nir</div></div>