JDK-8289171 : Blank final field 'dialog' may not have been initialized in scene.control.Dialog:521
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: openjfx18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-06-24
  • Updated: 2022-09-12
  • Resolved: 2022-07-07
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
openjfx19Fixed
Related Reports
Blocks :  
JDK-8289379 - ☂ Fix errors and warnings generated by Eclipse
Relates :  
JDK-8289777 - javac does not see a problem when Eclipse emits a 'blank final field may not have been initialized' error
Relates :  
JDK-8097791 - Add javafx.scene.control.Alert class
Description
Eclipse emits the following error:

The blank final field dialog may not have been initialized	Dialog.java	line 521	/controls/src/main/java/javafx/scene/control

This is caused by the final 'dialog' field being accessed from within a property listener which is initialized before the constructor, where 'dialog' field itself is initialized.

Suggested fix: move the 'dialog' field initialization outside of the constructor to force a proper initialization sequence.
Comments
I updated the wiki to remove the note about this error in Eclipse.
07-07-2022
Changeset: 4dcd9e06 Author: Andy Goryachev <andy.goryachev@oracle.com> Committer: Nir Lisker <nlisker@openjdk.org> Date: 2022-07-07 14:21:41 +0000 URL: https://git.openjdk.org/jfx/commit/4dcd9e0656a84ff6afb62656ac1cb81ff09a0f6b
07-07-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jfx/pull/815 Date: 2022-07-06 18:16:02 +0000
06-07-2022
Created https://bugs.openjdk.org/browse/JDK-8289777 against javac.
05-07-2022
I agree, I will contact javac group. For the purposes of this PR, I would like this fixed, since I consider this a problem. Here is a draft PR (has other dependencies, so please ignore files other than Dialog.java): https://github.com/openjdk/jfx/pull/810/files#diff-50a78b9ef58130ff0c9c09f967605bd81ade4a80320d96e97dec60838afe441e
05-07-2022
If you think it's a bug in javac I suggest you contact the compiler group. Eclipse treats the error as a bug. From what I understood, the specs don't cover this case.
05-07-2022
[~nlisker]: I believe it *is* a bug, one missed by the javac compiler. The key word 'final' suggests that the field 'dialog', being initialized in the constructor body, is not null. However, is *it* null before the constructor call, i.e. when other fields are initialized. So if someone adds another field that depends on dialogPane, for instance, or if a change is made to HeavyweightDialog which results in an access to dialogPane, a NPE will be thrown. Funny thing, I have encountered a similar issue before.
05-07-2022
This is known and has been brought up a couple of times in the mailing list, which is why I added a note about it in the Wiki: https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK. It's a bug in Eclipse's compiler. The working solution is to fix it locally and ignore it when submitting. git-stash can be helpful here. There is no merit to fix this just for Eclipse, but if it's bad in general and should be fixed, then Eclipse users will benefit doubly.
03-07-2022
This seems like a case of Eclipse being more strict than javac, since we don't get a build warning for that file during a gradle build (although we might if we turned on the right lint option). The reference in question to this.dialog is in a lambda, so unless that lambda gets executed during the construction of the property (which it doesn't look like it does), this isn't really a bug in practice, although it is fragile. We still should consider fixing it, though, since it is a questionable pattern.
24-06-2022