I think I can comment from the perspective of a successful user of JavaFX (we have been running an administration application for our medical software for over 5 years now) as well as a part-time contributor to the JavaFX project (with the help of Kevin Rushforth and Ajit Ghaisas my pull request https://github.com/openjdk/jfx/pull/383 was integrated into JavaFX a few days ago): * Yes, the closed bug tracker of OpenJFX is a bit of a nuisance but no, it is not the biggest obstacle when trying to contribute. * Contributing is hard because JavaFX is quite complex and there is a very stringent process in place. As a contributor this can sometimes be tiresome. As an example, when Kevin Rushforth asked for a better API comment in the aforementioned pull request, it felt like exxagerated attention to details. However, when trying to write that better API comment I discovered another bug in my pull request which would have broken things. So it might be a difficult process but it pays off in terms of quality. So as a user of JavaFX I absolutely want the quality and stability it provides. As a contributor I would sometimes like to have my pull request integrated more easily. Since I can't have both, I'd rather have reviewers nitpick at my next pull request (and thus ensuring quality) for a dozen times than having my application break down from regressions after I update to the next JavaFX version. * As a long-time user of JavaFX I would not like for javafx.controls to be split off and modified in a way that is less stringent than now. Because one users fix is the regression of another :-). * I think contributing to JavaFX is about as difficult as contributing to other projects of the same scale. You can't contribute to Qt easily and certainly not to the Linux kernel.
Am Mi., 3. Feb. 2021 um 13:24 Uhr schrieb <naast...@gmail.com>: > 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. > > > > > > > > > >
