JDK-8368719 : 6.5.6.1: Shouldn't allow field references before 'this()'
  • Type: Bug
  • Component: specification
  • Sub-Component: language
  • Affected Version: 25
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-09-25
  • Updated: 2025-12-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Flexible Constructor Bodies (JEP 513) allows assignments to fields in an early construction context, with some restrictions. We didn't anticipate one extra necessary restriction: assignments should not happen before an alternate constructor invocation.

This is a problem mainly because of future language evolution:

- We'd like to support early reads of fields, implemented via proxy locals. But a proxy local won't be preserved across a constructor invocation, so the assigned value will be lost.

- We'd like to support early references to fields with initializers, where initializers run "first" in the construction process; but the earliest initializers can be run is the start of a super-calling constructor, where they will overwrite whatever was written in a this-calling constructor.

- We'd like to support user-defined default values for non-nullable types, but again these initial values can't be written until the start of a super-calling constructor, overwriting whatever was written in a this-calling constructor.

The right model for users is that the prologue of a this-calling constructor exists at a uniquely sensitive point of construction—you can set up parameters to pass to another constructor, but you can't interact at all yet with the current object.
Comments
Note that the same rules should apply to 15.8.3 and 15.8.4
15-12-2025

Discussed how to resolve this, consensus was to: 1) Include the change as part of the preview behavior of JEP 401 2) After it's had a chance to stabilize and we're confident we're not going to change the rules further, consider adopting on its own into JLS and non-preview javac It may be that we just do (2) when JEP 401 becomes final, or that we discover some further adjustments that we want to make in preview before committing to the change.
02-10-2025

Suggested changes to 6.5.6.1 (with some editorial tweaks to make it easier to follow): If the declaration denotes an instance variable of a class C (§8.3.1.1), then all of the following must be true, or a compile-time error occurs: - The expression name does not occur in a static context (§8.1.3). - If the expression name occurs in an early construction context of C (§8.8.7), then**:** ~~it is the left-hand operand of a simple assignment expression (§15.26), the declaration of the named variable lacks an initializer, and the simple assignment expression is not enclosed in a lambda expression or inner class declaration that is contained in the early construction context of C.~~ - **The instance variable is declared by *C*, not a superclass of *C*;** - **The variable declaration lacks an initializer (§8.3.2);** - **The expression name is the left-hand operand of a simple assignment expression (§15.26); and** - **The expression name does not appear in a constructor of *C* whose body includes an alternate constructor invocation (§8.8.7), or a nested class or interface declaration of *C* (§8), or a lambda expression contained by *C* (§15.27).** - ~~The expression name does not occur in an early construction context of a subclass of C.~~ - If the expression name appears in a nested class or interface declaration of C, then the immediately enclosing class or interface declaration of the expression name is an inner class of C **(§8.1.3)**. > For example, the expression name must not appear in the body of a static method declared by C, nor in the body of an instance method of a static class nested within C.
26-09-2025

Can also delete this rule from 16 (it is impossible to break): ~~Similarly, for every alternate constructor invocation (§8.8.7.1) occurring in a constructor of a class C, every blank final instance variable of C declared in C must be definitely unassigned after the argument list of the alternate constructor invocation, or a compile-time error occurs.~~
26-09-2025