Proposal: Deprecate Builders

[Danno Ferrin]

On Mar 25, 2013 2:55 PM, "Richard Bair" <richard.bair at oracle.com> wrote:

> > 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.

You left out charts.

>From the outside, it looked to me that Builders were there to relieve the
collective guilt of killing off JavaFX Script.  This was before the uptake
of FXML.

I've played with the builders and am not too thrilled with them.  My
preferred workflow is FXML with code wired in the (IMHO poorly named)
controller class.  So losing them wouldn't be a loss on my end.  With
alternative languages like GroovyFX, ScalaFX, and Visage I think there
exist good alternatives for those who would feel a loss.

+1 to option B