JDK-8092861 : Remove deprecated builders module from JavaFX runtime
  • Type: Bug
  • Component: javafx
  • Sub-Component: scenegraph
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-01-09
  • Updated: 2017-05-18
  • Resolved: 2015-02-11
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.
JDK 9
9 b51Fixed
Related Reports
Blocks :  
JDK-8089907 - [FXML] Replace legacy WebViewBuilder with more generic builder class
Blocks :  
JDK-8092093 - Modularization support for JavaFX
Blocks :  
JDK-8094957 - Stop using deprecated builders in samples, toys, and other apps
Relates :  
JDK-8092142 - Annotation processor javafx-annotation-processor.jar publishing.
Relates :  
JDK-8156811 - Ensemble2 AdvanceMedia sample throws NoClassDefFoundError: javafx/scene/control/ButtonBuilder
Relates :  
JDK-8124188 - Deprecate builders
Sub Tasks
JDK-8175964 :  
Release Note: JavaFX builder classes have been removed - Closed
Description
We deprecated the builders in FX 8, and froze the definition and implementation to match FX 2.2, primarily due to the fact that the way we generate the builders means that we cannot maintain binary compatibility if the class hierarchy of the core API evolves (e.g., if a method moves from a subclass to a superclass).The stated intention at that time was to remove these from jfxrt.jar in a future major release of Java (e.g., JDK 9) and provide them as a separate jar that could ship with an application, such as scene builder, that needs it. See RT-30520 for information on this.

The builders present a problem with JDK 9 because the modular JRE does not allow classes from a given package to come from multiple modules. When we modularize JavaFX we will run into this limitation. We will need to fix this problem in JDK 9.
Comments
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/32b4f835090b
11-02-2015
+1
11-02-2015
Thanks, Jonathan. Here is the updated webrev ready for final review. http://cr.openjdk.java.net/~kcr/RT-39785/webrev.01/ There are very few changes since v00 (mainly just cleaning up print statements and comments) so I produced a delta webrev: http://cr.openjdk.java.net/~kcr/RT-39785/webrev.delta-00-01/ I filed RT-40037 to track the follow-on work of removing the (now-copied-to-an-internal package) remaining 4 legacy builder classes.
11-02-2015
Looks fine - no comments to add.
09-02-2015
Jonathan: can you please review the following preliminary webrev for this when you get a chance? I will send out a final review early next week, but wanted to get some feedback from you on the FXML piece. http://cr.openjdk.java.net/~kcr/RT-39785/webrev.00/ NOTES: The "straight-forward" solution I mentioned in my previous comment for handing the special case currently done via the WebViewBuilder is going to take a bit more time than I have now. Given that, I have generated a webrev that includes a brute-force solution to this issue by moving the existing WebViewBuilder, ParentBuilder, NodeBuilder, and WebEngineBuilder classes to an internal package in the web module. This can be replaced by JavaFXWebViewBuilder in a second pass or even in a follow-on JIRA. I included a skeleton JavaFXWebViewBuilder file with a brief description of how I think it should be implemented. Your thoughts on this would be helpful. The patch includes some debugging code in JavaFXBuilderFactory that will be cleaned up in the final version.
06-02-2015
Here is an update on the work for this. I have a local patch that removes the builders -- "hg rm modules/builders netbeans/builders" plus fixing up the gradle files to not reference the builders module / project. Now that the fix for RT-39831 has been pushed, the only remaining use of the legacy builders in the FX 9 forest is in the FXML loader, specifically, javafx.fxml.JavaFXBuilderFactory, and only then as a fallback if it cannot be constructed directly via a no-arg constructor or an annotated constructor (except for the special case of WebView highlighted below). There is also a now-unused code path (formerly used by an older version of SceneBuilder) in FXML that will force the use of builders everywhere, but that has been gone since before SB 2.0 (and wouldn't work correctly today if it were attempted), so can just be removed. As mentioned above, the one exception to this is WebView. JavaFXBuilderFactory forces the use of WebViewBuilder even though WebView has a default constructor. The reason for this is that FXMLLoader is taking advantage of the fact that WebViewBuilder provides setters for some properties from WebEngine, and delegates those propoerties to an instance of WebEngineBuilder constructed by the WebViewBuilder in its build() method. I will need to create a JavaFXWebViewBuilder like we do for ImageView, Scene, and a couple other classes. This will be straight-forward. To verify that there were no other cases which might need the builders, I analyzed all concrete, public classes in FX 8, after filtering out inner classes (which need to be constructed from an instance of the enclosing class), and classes with no public constructors at all. Of those concrete, public classes with at least one public constructor, here is a list of classes that do not have either constructor annotations or a default, no-argument constructor. These are the classes for which JavaFXBuilderFactory would currently try to find a builder. javafx.application.Preloader$ErrorNotification javafx.application.Preloader$ProgressNotification javafx.application.Preloader$StateChangeNotification javafx.css.StyleablePropertyFactory javafx.embed.swing.InputMethodSupport$InputMethodRequestsAdapter javafx.scene.chart.NumberAxis$DefaultFormatter javafx.scene.chart.PieChart$Data javafx.scene.control.CheckBoxTreeItem$TreeModificationEvent javafx.scene.control.ListView$EditEvent javafx.scene.control.TableColumn$CellDataFeatures javafx.scene.control.TableColumn$CellEditEvent javafx.scene.control.TableView$ResizeFeatures javafx.scene.control.TableView$TableViewFocusModel javafx.scene.control.TreeItem$TreeModificationEvent javafx.scene.control.TreeTableColumn$CellDataFeatures javafx.scene.control.TreeTableColumn$CellEditEvent javafx.scene.control.TreeTableView$EditEvent javafx.scene.control.TreeTableView$ResizeFeatures javafx.scene.control.TreeTableView$TreeTableViewFocusModel javafx.scene.control.TreeView$EditEvent javafx.stage.FileChooser$ExtensionFilter I verified that none of them have an existing Builder class, so cannot be constructed directly in FXML even in FX 8. I should have a webrev ready for review / testing in the next day or so.
05-02-2015
For all the reasons listed above, we plan to remove the classes from the JavaFX 9 runtime. We will explore ways to make them available to applications that still want to use them, but it will not be possible to do it in a binary compatible manner -- they will need to move to a new package to avoid the split package problem. Most likely we will just provide a sample with source code.
21-01-2015
#3 would need the same package renaming as #2.
12-01-2015
@Kevin: If we did option #3 and then provide a separate jar file, do you anticipate that this jar file will use the existing package naming, or a different package naming (such as that suggested in option #2)? What I'm really asking is if we will run into the split package restrictions if all we do is move the code to a new, separate jar file? My _guess_ is that we will run into issues, so we will need to use a new package name (as you note, javafx.xxxxxx.builder seems reasonable). If this is true, my vote would be to do option #3, and to provide the separate jar file somehow (or encourage the community to do so with the help of a continuous build server). I see no sense in keeping the builders around, so I would disagree with taking option #1.
11-01-2015
I see three choices to fix this bug: 1) Fold the builder classes into the respective modules that contain the other classes for each package. This would mean that we have to continue supporting something that is deprecated and is not evolving -- no classes added in 8 or later have a builder. 2) For each package javafx.xxxxx containing a builder, create a new javafx.xxxxx.builder package and move the builder classes to there -- this breaks binary and source compatibility (which we said we were going to do anyway if we removed them), but still keeps builders as its own, optional module. Also, any apps that are still using builders in spite of their being deprecated don't have to figure out how to deliver the builders classes. 3) Remove the builders from FX. We could provide a separate jar file (or instructions as to how apps could bundle it themselves). I prefer #3. I suspect that #1 might be less effort (and avoids breaking apps still using builders), but it means we will be stuck with the builders forever. I think #2 is the worst of both options.
10-01-2015