Proposal: Deprecate Builders

[Richard Bair]

> 1. FXML? It uses builders pretty heavily I believe and I'm pretty sure
> anything I've written in JFX would instantly and dramatically break if they
> dissapeared. I imagine there is also a code dependency between fxml code
> and builders so removing it might be tricky?

I believe FXML *can use builders* but for all the built in classes it does not. And the builder base class would remain in the API, so people can still use that feature of FXML if they choose, but we just wouldn't be producing them all.

> 2. This splitting out into separate JARs is a little along the lines of
> jigsaw, could/should it not be used here (when is jigsaw happening?)

Yes and no. Jigsaw is not planning to support split packages, so you couldn't just put them in their own module.

> 3. If we start splitting out jars we open up the door for something I would
> have preffered in the first place. Move any non-core library out (e.g.
> jfx-charts, jfx-fxml, etc). These are not JVM (i.e. operatin system) level
> libraries in my opinion and would work much better as separate libraries.
> Reduce the bloat (especially for mobile) and have less rigid constraints
> than the JRE e.g. separate release cycles, ability to change/deprecate
> stuff more like other libraries (spring, hibernate, etc), ability to use
> other libraries (e.g. an xml parser or a math library).

Most customer I've met see controls as core and fundamental. Mobile needs controls as much as anybody else, so they aren't bloat for mobile. Mobile needs tooling just like anybody else, and FXML provides that tooling. None of the things in the core platform are not essential IMO.

> This last point likely will be contentious but having these out in
> something philosophically more like swingx would be better for everyone in
> my opinion. It's the code the community can and probably want to evolve (as
> opposed to media, rendering, 3d, etc) and there's no particular benefit to
> it being in the JRE only costs involved. Doesn't mean Oracle can't
> sanction/support/manage/contribute, etc.

In Java 8 the "components" (graphics, base, swing, swt, fxml, media, controls, web) are all going to be separable so that you can run a VM with only a subset of these components. That's already happening.

Splitting any of these modules out into yet another open source project would have no clear benefits. We already don't have any of the process-imposed burdens of the JDK (such as the JCP process), but still get the benefits (wide distribution). The self-imposed constraints like maintaining compatibility wouldn't be different in an external project as in openjfx -- we would still operate the same. Of course anybody is free to fork and make a better project!