Proposal: Deprecate Builders

[John McDonnell]

If this is targeted for Java 8, would it not be better to do away with the
builders in one swoop?

There doesn't seem to be a clear approach to fix this issue for all
affected components, and as Java 8 is a major release, would it not be best
to completely remove them from Java FX 8? As opposed to separating them out
into a separate Jar, which doesn't fully fix the problem at all, which will
only just get removed anyways in Java 9?

If people still need builders, maybe a library whose goal would be to fix
them up, could be created by the community as a 3rd party library?

John

On 26 March 2013 15:49, Eva Krejcirova <eva.krejcirova at oracle.com> wrote:

> Hi,
>
> I'd like to add some more info for anybody who is interested in what
> problems we are facing with builders:
>
> We currently have two major problems with builders:
>
> * the create() method (RT-24272) *
> It's not possible to call the create() method for generic builders and the
> current attempt to solve this doesn't handle builders creating generic
> classes themselves.
> e.g. trying to compile TableView<String> tableView1 =
> TableViewBuilder.<String>create();
> results in
> "reference to create is ambiguous, both method create() in
> javafx.scene.layout.RegionBuilder and method <S>create() in
> javafx.scene.control.TableViewBuilder match"
>
> It was possible up until Java 7 because of some bugs in JDK 6, which were
> now fixed. Currently, the builders compile, but it's not possible to
> compile a user code which tries to call such create() method. It's possible
> that in the future the builders themselves won't even compile when more
> bugs in javac are fixed.
> This problem is actually present even in JavaFX 2.2 with Java 7 (in
> builders for charts).
> This also means that if we just move the builders in separate jar file in
> the state they are now (or were in 2.2), some of them will be unusable.
>
> (Actually in current code we have half-baked attempt to solve this (added
> TableView.create(Class<?>))  so you can call create() for some cases, but
> it's not a real solution as it doesn't work for all cases)
>
> * binary incompatibilities when moving methods to superclass in scenegraph
> *
> When we move some method to superclass in the scenegraph hierarchy (let's
> say change Shape.fill() to Node.fill()) this is OK for the classes in
> scenegraph. However, since the builder methods return generic type, this
> creates binary incompatibility in builders. Currently, we solve such
> incompatibilities manually (e.g. RT-24540) which is extremely error prone.
>
> More info can be found in https://javafx-jira.kenai.com/browse/RT-24272
>
> Regards,
> Eva
>
>
>


-- 
John