In order to separate the "What" from the "How" (discussed in another thread), I would like to start a discussion about what people think should be considered for future JavaFX work.
I'd like to start with what I think is an important note on the context. If I want feature X in JavaFX, I ask myself two questions: 1. Do I want to contribute time and do it (at least for a large part) myself? 2. Do I want to spend money on it? If that sounds too economic or commercial, I recommend reading the excellent blog entry by David Blevins about funding Java EE development (more than 4 years old and still very relevant): http://www.tomitribe.com/blog/2013/11/feed-the-fish/ Actually, this is a model we've been using at Gluon for a number of customers. When people ask us about a specific feature, we ask if they are willing to pay us for the development, AND if they are ok with us donating it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX, JavaFXports, Gluon Charm Down, Gluon Maps,...). As a consequence, the features we are working on are all relevant to (at least a part of) the industry. Some companies doubt there is business value in JavaFX, we prove the opposite while making the Open Source community better. I think by now it should be clear to all that there is no free lunch (anymore). If your business depends on a feature being added to JavaFX, how much (time/money) are you willing to contribute? If the answer is "nothing", you can still hope that others want to do it, and in many cases that will eventually happen -- but you don't control the timeline. This principle is a bit a simplification though. In many practical cases, people want to have feature X and are willing to contribute "something" (e.g. they want to work on it in spare-time, or fund 20% of a developer) but not enough to do everything. I think in this case it's a matter of gathering enough interest in this community. Once enough developers are interested in that same feature, and agree to spend resources on it, the burden can be shared. Having a sandbox repositories with forks will make this easier. Areas that I personally want to see on the roadmap: * more alignment with mobile * a clean and lean low-level rendering pipeline API that would allow easier plugability with upcoming low-level rendering systems * extensions for Chart API - Johan
