Make javafx.controls open and community-driven

Wed Feb 3 13:31:04 UTC 2021

I assume since JFX stated with and was closely coupled with Java prior to being removed from the JDK/JRE, this allow for the link up with the java bug link.

The case could be made it could be similar to the other library’s. I believe some other existing libraries (JAXB?) were removed [maybe more for modularity and smaller profiles but] in favor of the having dependency when needed but allowing development separately as independent projects but the specific I’m a little fuzzy on).

Since JFX was Sun/Oracle IP, I assume this also accounts for some of the restrictions. As I understand in the grand open bizaar scheme that if there are areas that are closed, re-implement and replace it with open where applicable.

Now with all those comments out of the way...

Regarding the decoupling java fix.controls...With modularity in mind, would it be worth having a service layer / package / module interface added in some way and then make existing controls implementations of the service then further improvements could implement and/or extend as preferred as implementations of this?

Eric Bresie
Ebresie at gmail.com (mailto:Ebresie at gmail.com)

> On February 3, 2021 at 6:24:20 AM CST, naastonn at gmail.com (mailto:naastonn at gmail.com) wrote:
> What do you think about decoupling javafx.controls from other modules private API? Is it possible? In current situation
> it may be the best solution, because this would allow to fork it. So, those who interested could play with fork(s) and
> backport changes when neccessary. It would also allow to develop other controls libs, those aren't based of
> javafx.controls, e.g. just for mobile.
>
> Best regards
> Mike
>
> On Tue, 2021-02-02 at 13:40 -0800, Kevin Rushforth wrote:
> > There are two separate issues here. I won't address the first point from
> > the initial poster, other than to say that I understand that the lack of
> > direct write access to JBS for occasional contributors is a pain point.
> > I don't think it is stopping anyone from contributing, though. As for
> > the other part of this point, JavaFX is already on GitHub along with the
> > rest of the JDK, and it's easy enough for someone who is motivated to
> > provide a pull request for a bug fix.
> >
> > The more interesting question is the one about extensibility that others
> > have also responded to. This raises the question of which areas are most
> > in need of new public API to facilitate this. "Just make every internal
> > detail of your implementation public or protected" isn't the right way
> > to frame the discussion. Anything that makes it into the public API is
> > something that needs to be documented, tested, and supported. It
> > requires us to consider what it means to support that API forever; we
> > take compatibility seriously. The main idea is to think in terms of
> > "stewardship" when evolving the JavaFX API.
> >
> > Keeping that in mind, there are certainly areas that could be made
> > easier to extend. Two things in the UI Controls area that were brought
> > up are skins, which are public API with not all of the fields and
> > methods of the skins are public/protected, and behaviors. The former
> > isn't too difficult to address. It requires some amount of thought,
> > discussion, API documentation, implementation, and testing, but doesn't
> > need a whole new design. VirtualFlow has been extended in this fashion
> > to provide missing pieces for third-party controls. If there are others,
> > developers can propose them and we can discuss them. This is definitely
> > an area we would welcome well-thought-out contributions in.
> >
> > The harder area is that of behaviors. For a little background, a public
> > behaviors API was originally part of the proposed new public API for FX
> > in JDK 9, which was done via JEP 253 [1]. It was decoupled from that
> > JEP, but still remains an open enhancement request tracked by
> > JDK-8091189 [2]. That JBS issue has a very long discussion thread about
> > possible approaches for the API. This would be a very large effort, and
> > would require someone with a very good understanding of both UI control
> > design in general and the design and implementation of JavaFX UI
> > Controls in particular to lead the effort. It isn't something that we
> > would accept from an application developer who is just wanting to make
> > their life easier. Again, think of it in terms of API stewardship. I'm
> > not saying there is no way this could be done, just that it's unlikely.
> >
> > I'm sure there are other areas outside of UI controls that could be made
> > more extensible, too (although knowing how fragile CSS is, I wouldn't
> > have much enthusiasm for that). What we would need is a concrete
> > proposal that we could discuss.
> >
> > -- Kevin
> >
> > [1] https://openjdk.java.net/jeps/253
> > [2] https://bugs.openjdk.java.net/browse/JDK-8091189
> >
> > On 2/2/2021 6:30 AM, Michael Paus wrote:
> > > 1+
> > >
> > > Am 02.02.21 um 15:12 schrieb Pedro Duque Vieira:
> > > > Hi,
> > > >
> > > > Although I don't agree with everything said here at the start of this
> > > > thread, I agree with the base idea that JavaFX would benefit from being
> > > > more open than it is currently. It's something I've already said here in
> > > > this mailing list and since it's been a while and that discussion
> > > > probably
> > > > already got forgotten I'll add the comments to this thread again.
> > > >
> > > > Not even just the controls case but more hooks to extend JavaFX just
> > > > generally by adding API that allows for that and making things less
> > > > private/final/etc. It would be great to be able to extend more parts of
> > > > JavaFX in a library independent way (i.e. by creating your own
> > > > library that
> > > > extends some parts of JavaFX in more fundamental cool way).
> > > > Besides what was already said about controls, here's another example:
> > > > wouldn't it be great for the community to be able to create a library
> > > > that
> > > > could extend the CSS parser by adding animations, layout support,
> > > > etc, etc.
> > > > One could argue, why don't you just contribute a PR to the JavaFX
> > > > code base
> > > > that does just that (adds animation support to CSS, or something less
> > > > trivial like that)? I'd say that that process is too lengthy and
> > > > often out
> > > > of possibility for an individual developer that wants to improve
> > > > JavaFX but
> > > > doesn't have time to do it that way.
> > > >
> > > > I see the advantage of exposing less of the internals and why the JavaFX
> > > > team decided to do it. Many of the same guys that developed JavaFX were
> > > > part of the Swing team which were bothered by the inverse situation,
> > > > i.e.
> > > > being too open (which also can have its disadvantages).
> > > > Weighing in the pros and cons, I still think there's a bigger
> > > > advantage in
> > > > being more open than closed. This hinders the capacity for the
> > > > community to
> > > > create libraries that extend JavaFX in new and fundamental ways without
> > > > having to fork JavaFX.
> > > > And this is more of a reality now that the JavaFX team is smaller
> > > > (than the
> > > > original team) and hence has less capacity to keep improving and adding
> > > > features to JavaFX which means it has to rely more on the community.
> > > >
> > > > I also agree with the process of submitting a bug and following upon it,
> > > > commenting, etc. Ideally it should be easier. That's something that has
> > > > also been brought up before.
> > > >
> > > > Anyways, this mail is not meant to put down the guys working on
> > > > JavaFX, there are no perfect toolkits, each one has its downfalls.
> > > > Think it
> > > > more like throwing in ideas and sharing my experience of using JavaFX
> > > > for
> > > > creating libraries and applications.
> > > >
> > >
> >