Kevin, thanks for sharing those plans. How much of a priority are quality issues, especially on the Mac (which clearly is a second-class citizen as far as JavaFX is concerned)? Are things like flashing when opening Stages, bad rendering performance, broken media APIs etc. an issue? As far as my company is concerned, the biggest problem (which resulted in us reluctantly dropping the idea of a migration of our product to JFX for the time being after lengthy evaluation) is not so much lack of features but primarily quality in terms of robustness and user experience and the number of problems we have run into in almost every area that we did tests in was what led us to that decision (especially with Mac being our most important platform).
Is there awareness that there are serious problems of the described kind that block the adoption of JFX in companies who desperately want to switch? It's always difficult to judge that by the priorities in Jira but it appeared to me that in many cases the perception on the Oracle side was very different, if things like the white flashing problem when opening windows or the tree view scrolling incorrectly or looping in a media api not working seemed to be viewed rather like a minor glitch. People have different requirements and thus different views on the topic of this thread but I found the analysis and observations in Shay's posting not very far from that of our own engineering team (no affiliation with him or his company btw.) for the reasons described above. Best regards, Robert On Wed, Dec 2, 2015 at 1:29 AM, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > Just to chime in on a couple of points that have been raised in this > discussion... > > * We are interested in working with the OpenJFX community to improve > JavaFX. In particular: if you find a bug, file it (via bugs.java.com if > you don't have a JBS account); if you want to contribute a patch to fix the > bug, we'd love to review it; if you have an idea for an improvement, file > it as an RFE (enhancement) and start up a thread on the mailing list. > Larger features need a JEP, but smaller improvements do not. > > Please be aware that as part of the OpenJDK community, we are bound by the > processes of the OpenJDK, including the need for a signed OCA in order to > contribute, and before you can get a JBS account. If you are dissatisfied > with those processes and policies, then I invite you to discuss it on the > disc...@openjdk.java.net alias, and not here. > > > * While we aren't planning a huge number of features in JDK 9, we are > delivering some interesting improvements. Jigsaw is the big release driver > and most of our effort on JavaFX is to align with that. For those of you > who weren't at JavaOne, here is a list of things that are currently planned > for JDK 9: > > - A modularized JavaFX (into 6 core modules + deploy, swing interop, swt > interop) > > - JEP 253 -- Control Skins & additional CSS APIs (proper support for > third-party controls) > > - High DPI enhancements (full support on Windows; add support for Linux) > > - Public API for commonly used methods from internal packages: > * Nested Event Loop > * Pulse Listener > * Platform Startup > * Text API (HitTest, etc) > * Static utility functions (under investigation) > > - New versions of WebKit and GStreamer > > And here is an incomplete list of things we are thinking about for after > JDK 9, possibly in an update release. In fact, the recently proposed JDK 9 > slip [1] makes it possible to consider pulling a few of them into JDK 9, so > let us know which ones you consider most important: > > - Provide a JavaFX equivalent for JEP 272 / AWT ‘Desktop’ API > > - Make UI Control Behaviors public > > - UI Control Actions API > > - Public Focus Traversal API > > - JavaFX support for multi-resolution images > > - Draggable tabs > > - Image IO > > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html > > -- Robert Krüger Managing Partner Lesspain GmbH & Co. KG www.lesspain-software.com
