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 inthis mailing list and since it's been a while and that discussion probablyalready 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 ofJavaFX in a library independent way (i.e. by creating your own library thatextends 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 basethat does just that (adds animation support to CSS, or something lesstrivial 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 butdoesn'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 werepart 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 tocreate 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 theoriginal 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 onJavaFX, there are no perfect toolkits, each one has its downfalls. Think it more like throwing in ideas and sharing my experience of using JavaFX forcreating libraries and applications.
