Hello. JavaFX is a great toolkit, which personally I like a lot, but it's slowly dying for the past 5 years. You can barely argue with that. Most of the devs still prefer Swing. Have a look how many topics like "JavaFX is dead" on Reddit or similar resources. Look how many community libraries are abandoned or badly maintained (https://github.com/mhrimaz/AwesomeJavaFX), including most popular ones, like ControlsFX. Look how small the numbers of real-world JavaFX apps. Also notice that no major Java apps adopted JavaFX or have plans to use it in any near future. Eclipse sticks with SWT, NetBeans uses FlatLaf (https://github.com/JFormDesigner/FlatLaf) and JetBrains puts lots of resources into JetPack Compose. They even implemented interop layer for Swing apps (https://blog.jetbrains.com/cross-post/jetpack-compose-for-desktop-milestone-2-released/).
OpenJFX team is understaffed while modern desktop and mobile applications require more components that JavaFX could provide (and support) at the moment. javafx.controls are outdated and Modena theme doesn't look pleasing anymore. But that's not the worst part about it. The worst part is that it's almost impossible to extend existing components. I do understand that current resources and maintainers time are very limited and maintaining graphics layer should be top priority. The only thing I ask is to REMOVE BARRIERS that stop those who want to improve standard controls. Make javafx.controls fully open. Allow community to fix things that you don't have time to fix. 1. The first obstacle is JBS. It's read-only for everyone, but OpenJDK maintainers. But OpenJFX is not a part of OpenJDK, not anymore. No other UI library imposes strict limitations like these. Check Electron, Avalonia, WXwidgets, even god-damned proprietary Qt. While it may be the case for low-level stuff like javafx.graphics it's absolutely unacceptable for controls. You're stopping a lot of people from commenting existing bugs and sharing their workarounds and any feedback they could provide. Moreover you require signing OCA from everyone who want to commit into controls even if it's a slightest improvement. 2. Controls implementation is hidden for NO GOOD REASON. Almost everything in skins is private and things like *Behavior are module-private. Hello, fellow users! Wanna DatePicker w/o text field or TreeCell w/o disclosure node? Sorry, you can't w/o re-implementing everything from scratch. This is effectively stops everyone who want to improve current skin for it's own project or create a library that extends current controls. https://github.com/sshahine/JFoenix/issues/955 https://github.com/controlsfx/controlsfx/wiki/Using-ControlsFX-with-JDK-9-and-above That's why JS is so popular. No self imposed limitations! Everything is customizable, manipulate the DOM in any way you want. 3. javafx.controls i18n support is very limited (https://github.com/openjdk/jfx/tree/jfx16/modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/ resources). You've put a lot or resources in thing like RTL implementation, but who cares if there's literally no API to customize standard controls. Back to #2, it would be possible if you'd opened skins for customization or/and reflection. Summary: - Move javafx.controls support to the Github (not to javafxports, it's outdated and barely maintained). Mark issues: "good first issue", "help needed" etc. Everyone do this, because it helps to encourage new devs to participate into development. This is exactly how social coding works. - Allow community to extend and improve controls in any way they want. Export "com.sun.javafx.scene.control" (esp "com.sun.javafx.scene.control.behavior.*") and make everything "<? extends Node>" inside skins protected, not private. I beg you to hear me. Controls are just controls, it's not a platform thing, it's not something sacred you should keep in private. You can't possibly foreknow all possible uses cases. By stopping to extend them you just lose your users and that's it. They simply go away and use more extensible and feature-rich alternative. Ironically, even Swing beats JavaFX in that case. We need more libraries like JFoenix and ControlsFX. Without that you can't compete with either Flutter or Compose in near future. You literally doom JavaFX to stay a bunch of legacy controls no one really like or want to use. Ideally javafx.controls should not rely on private javafx.graphics or javafx.base API at all. - Be open. Stop hiding in mailing lists. There's no corporation behind JavaFX, it won't survive without community. There's https://www.reddit.com/r/JavaFX. Share your plans, make regular announcements, discuss what need to be improved. Guide community efforts! - Invest some time into i18n support. There's no way to localize controls w/o dirty hack (https://pastebin.com/RgadNwZd). If you'd removed JBS/OCA barrier for javafx.controls more people could help you with that. Even w/o that you could just ask people on Reddit to translate controls.properties (it's really short) into their native language and commit it yourself. Thanks for reading this. Best regards Mike
