Proposal: Deprecate Builders

[Daniel Zwolenski]

Just a comment on the sort of "shame to see builders" go thoughts: as I see
it they are just moving out of the JRE and into a separate library. So they
are not "going" anymore than say log4j is "gone" or spring, groovy,
hibernate, or your favourite PDF generator or XML parser.

You just need to include the jar as a dependency in your project. This is
actually much more 'normal' Java business as usual and the java ecosystem
out there is built around picking and choosing which libraries/jars you
want to add on top of the Java Operating System (JVM) which (should) just
provide OS level functions that are mapped to local OS functions.

In fact moving builders out means they can be improved much more rapidly
than when in the JRE, so for people who use builders this is actually a
win. Say you want a new builder method on the Node base class (e.g. to set
a tooltip). When built into the JRE you will be looking at a year turn
around if you are lucky. In an external library there's no reason it
couldn't be added and a new build pushed out before the end of the week.

If you use something like Maven, or Ant+Ivy or Gradle, you simply up the
version number and next build it will download the new jar for you. A lot
easier than upgrading your JRE version which may mean completely reworking
your app (e.g. when the JFX team decide something else was a bad decision
and need to change it).

Just pointing this out as I think the fear of "losing builders" is not
really a strong reason for not separating them out from the core libraries.
To me the question is more about is it technically feasible and are there
any things that would break if it did move out (e.g. FXML, Scene builder).

As I mentioned earlier I'd be a huge fan of doing this with things like
FXML and Charts but I know that's against the grain and a bit off topic.
The reasons would partly be bloat but more to allow these things to use
external libraries (xml, expression languages, etc for fxml, maths, pdf
export, etc for charts) and to be upgraded much more frequently than the
Java release cycle (instead of waiting a year for mouse overs on a chart
line or for injected builders in FXML, etc).







On Tue, Mar 26, 2013 at 9:19 AM, Milan Kubec <milan.kubec at oracle.com> wrote:

> Hello,
> I've inherited FXML codebase from Greg Brown, unfortunatelly I haven't
> inherited the history of design decision process and Greg's experience
> with declarative UI languages. FXML uses some builders from JavaFX API,
> but only those that cannot be substituted by other means of creating
> scene graph nodes, i.e. default constructor, valueOf(), fx:factory, etc.
> There are also some builders implemented even in FXML package itself for
> special cases (i.e. ImageBuilder).
>
> I will do deeper analysis of what would deprecation of Builders mean to
> FXML and post it to the mailing list.
>
>   Milan
>
>
> Dne 25.3.2013 21:53, Richard Bair napsal(a):
> > Aren't you on vacation too?? :-)
> >
> >> I think there are a few things in standard FXML that are fairly
> dependent on Builders. I cant remember exactly and its hard for me to look
> up currently (there's no way to browse the OpenJFX source online is there?)
> but from memory often when I tried to port between FXML and code there were
> magic methods not available in the code so I assumed builders were the
> source.
> > I know there is some stuff in SceneBuilder (where it tries to determine
> the default value of a constructor parameter I think), I'm not sure how
> much of it leaks into FXML. I *think* they are separable for the core
> libraries but I'm not totally sure.
> >
> >> e.g. can you create a colour in FXML directly, fonts, images? Stuff
> like that. I suspect at a minimum some of the tutorials will need updating
> to not use convenience builder methods.
> > These things end up using the "valueOf" methods that were added to the
> various classes IIRC
> >
> >> Also, Im again guessing but for FXML to optionally use builders doesn't
> it need to have a dependency on the builder class? I suppose it could all
> be reflection based, avoiding the compíler dependency, but it would still
> be quite weird for the core JFX code to be looking for a class that is now
> effectively third party.
> > I think the Builder class itself would stay, but the various builders
> that we built would be deprecated.
> >
> >> Who inherited FXML after Greg?
> > Milan Kubec!
> >
> >> Dont get me wrong, Im in the "strip them out camp", but just making
> sure all the consequences are thought through. Probably any such problems
> can be fixed but only if done in advance.
> > +1
> >
> > Thanks
> > Richard
> >
>
>