We really depend on JavaFX at Codename One, our simulator needs it. Our desktop build uses it and our designer tool is based on Swing. We want it to succeed, its important to our business! We are not alone, even if you are a Java EE developer and don’t care about desktop programming, keep in mind the fact that today’s desktop technology is tomorrows server technology. E.g.: C++ and Windows (a desktop technology) took the servers from Unix and C. Only to be replaced by Java (up until then a web based Applet language) and Linux. JavaScript might not look as a JavaEE contender today but as more developers come out of college liking JavaScript and not Java this will affect us all.
Note: If you are a fan of JavaScript/NodeJS or any other such scripting language then you are not the intended audience for this post… This post is for people who love working with Java and want it to move forward.
If anything, they are rearranging the deck chairs on the Hindenburg!
Stephen Colbert
When we rented a booth at JavaOne 2014 we got the impression that 90% of the Java developers we talked to were enterprise developers. Most of the exhibitors and the highest attended talks were also enterprise oriented. As a mobile tool vendor this is a much harder divide to cross than the one between desktop development and mobile. It highlights the fact that we need JavaFX to work or make way for something better but we need a GUI solution now.
This post isn’t about whether JavaFX sucks or not. Its not about whether its a good API and it isn’t about whether you can create nice looking apps with it (you can). Its about fixing JavaFX or moving away from it to something else, its about acknowledging the problems within it rather than presenting an aura of “everything’s fine” to fresh Java developers.
Initially I wrote about some technical issues in JavaFX as well. I decided not to go into that discussion. I have the utmost admiration and respect to the guys who created JavaFX. Its impressive in many ways. But good technologies also fail and in the next few sections I’ll try to elaborate on this:
- Reasoning – Why we all need a Java desktop API strategy
- Proof – read this if you don’t think there is a serious problem with JavaFX’s traction
- Why Should We Care? – If you are a Java EE developer who thinks this isn’t your concern please read this.
- What Are The Options? – how do we move Java forward.
- How did we get here? – if you are new to Java and this discussion is missing historical context read this first.
- Final Word – my personal take on the facts I listed here.
Reasoning
The first step in solving a problem is admitting that we have one and right now JavaFX is a problem that the Java community tries hard to avoid. Swing was pretty stable and while it had its share of issues/pitfalls it had its own reasonable traction. JavaFX still hasn’t attained that status but just in case you aren’t on the same page as I am we’ll review the evidence in the next section.
This isn’t an easy post to write and I’m sure it isn’t easy to read, but its a discussion that just isn’t happening in the Java community and should happen. New developers coming into Java every day are introduced to JavaFX without truly understanding its problems. The thing that made me write this post was this blog post that was mirrored by Java Code Geeks here. I would argue that while the post is truthful (in a very subjective way) it also enforces a false impression of the status and perception of JavaFX. This is very troubling when we try to convince young students to pick up Java, we don’t want them to be disillusioned later on.
The problems with JavaFX can’t be addressed if we don’t accept they exist. The current users of Java FX consist of 3 archetypes: corporations with huge Swing investment, students & hardcore diehard fans. While all of the above are totally fine, you can’t grow a community based on that. The corporations aren’t building new things, the students will graduate to do something else and the hardcore fans… They might be left with nothing as the platform declines. I’ll cover the “why should we care” down this post but first lest talk about the proof for the hardcore fans.
Proof JavaFX Doesn’t Have Traction
Exhibit A: Oracle Doesn’t Use JavaFX
I can go on about this but the facts are pretty clear. Even Swing based Oracle products aren’t moving in the direction of JavaFX. I can go into the firing of the evangelists and some of the teams within Oracle working on JavaFX but that seems redundant. I would like to point out though that Oracle no longer distributes Scene Builder, yes I know its still available elsewhere but if you are looking for signs of what Oracle is thinking… The messaging is pretty loud and clear.
Exhibit B: JavaFX Hasn’t Gained The Traction Of Swing
Stack overflow was launched on “September 15th, 2008”, this is important since JavaFX was launched released on “December 4th, 2008”. Effectively StackOverflow was brand new when FX came out with all of its PR glory and Swing should have been on the decline. There was very little time where StackOverflow existed and JavaFX didn’t exist.
The above essentially means Swing should have far less question tags on StackOverflow compared to FX, surprisingly the numbers here are pretty staggering and decisive… There are 11,565 questions tagged JavaFX, this makes sense for a 7 year old highly visible and widely promoted project. However, Swing which should have declined during this time has 56,434 questions which indicates to me that even the Swing developers who are the CORE demographic of developers for FX haven’t migrated.
Now to be fair, JavaFX transitioned between JavaFX script to the Java based JavaFX. But that should have caused far more questions and confusion within the community. The “reboot” so to speak generated attention all over the place and should have mapped to usage numbers. This is really punctuated by this illuminating graph from Google trends:
Notice that Swing (which had some traction) declined, JavaFX remained low and effectively competes for attention against Swing rather than growing. This chart might be read as “desktops lost interest to mobile and web”, which would be true and acceptable as an answer (see my discussion below) but the fact that FX can’t even beat Swing indicates a far larger problem at play. But lets compare it to another company in a similar situation that had a desktop oriented tool that was popular and got swept by web/mobile:
As you can see, the much maligned Adobe Flash is more relevant than Swing/FX by orders of magnitude according to the (unscientific) Google trends.
Exhibit C: Dice.com Agrees
While I don’t think you should pick a technology because of the job market, it is an indication of the state of the market. Searching thru dice.com for JavaFX netted me 28 positions of which only 4 placed Java FX as a requirement to the job (I checked one by one which is possible when you only have 28!). “Java FX” only listed 12 options. But this is where it gets interesting… Swing had 198 positions! JavaEE had 16,752 positions and Android had 2,333 positions.
To be fair there was a job as a NASA contractor that did look pretty sweet in the Java FX search but I think that combining all of the above conclusively demonstrates that JavaFX lacks traction.
Why Should We Care?
If you are a fan of JavaFX then this is a no-brainer. Skip ahead. But the rest of us should care deeply since desktop programming is important to the health of the Java ecosystem as a whole. One of the big benefits of Java was the skill transferal/tool portability between mobile, desktop and backend. The ability we had as developers to move between the datacenter and the front office was unparalleled in our industry!
Java is now challenged on all fronts: NodeJS/Ruby etc. on the server side, iOS on mobile & HTML+JavaScript on both mobile and desktop. If the client team doesn’t write the app in Java then why use Java on the server? Won’t it be more convenient if the client team and server team speak the same language?
Yes mobile plays a big roll here and JavaFX (or desktop) wouldn’t take over from the web. However, in the enterprise Swing dominated well after the rise of the web and JavaFX was able to lose that advantage. Losing that ground might cost Oracle the very lucrative JavaEE market and it might cost us in skill decline as our specific set of skills experience less demand (yes we’d still make money just like the COBOL guys do, it just won’t be as much fun maintaining a legacy system over cutting edge stuff).
We still need a desktop development API to build our IDE’s, our control consoles and do practically everything on our machine. Desktop development API’s are also tremendous teaching aids, getting a UI up and running is far more conductive to the teaching process than getting some webservice deployed. If you want a future generation of Java developers we need a decent UI option. Some of you JavaEE developers out there (or play framework fans) might jump on the HTML bandwagon for teaching…
I think that’s a better solution than teaching Java FX but effectively its still harder than desktop programming and you are then in direct competition with JavaScript tools which have a “home court advantage” as students would probably rather learn 2 languages instead of 3 (HTML+JavaScript only). Todays students sometimes learn JavaFX or Swing in class and often find out that they learned yesterdays technologies as they leave the classroom! Even if you never intend to write such a UI the ability to do so in Java is crucial to all Java developers!
What Are The Options?
Hopefully you reached this point agreeing (at least partially) that there is a problem. I think one of the problems is unclear messaging from Oracle about its commitment (or lack thereof) to JavaFX. Their representatives say unofficially that Oracle never discontinues products. That’s pretty accurate. However, Swing has been pretty much abandoned and it feels that way.
Fix & Promote JavaFX
Only Oracle can do this. While Java is bigger than Oracle and would continue even if Oracle stops all activity the same cannot be said for JavaFX. The community has made some efforts for quite a while but something as ambitious as JavaFX requires serious backing and if Oracle can’t get behind JavaFX 100% then it will keep declining and drag Java down with it.
Acknowledge That JavaFX Will Never Pickup
This is what I’m advocating. JavaFX is here to stay in the same way that AWT was, but once we accept that its never going to amount to more than its current limited scope this opens up the possibilities for client side development in Java. It also means we should start focusing on new things and maybe something can emerge as a replacement.
I think that the most important thing to do here is to move students off of JavaFX and into more sustainable areas in Java such as the newer server/HTML frameworks or to mobile, this will still provide some of the pleasurable “tingle” of seeing your UI run but would provide a more sustainable skill set. I’ve spent several days trying to come up with a potential replacement to JavaFX on the desktop and unfortunately there are no serious contenders at this point in time. Maybe one of the contenders I listed below will rise to the task:
- SWT – SWT hasn’t matured well. When it was designed modeling it to the Win32 API seemed like the right thing to do but with the move to mobile and Macs its now a problematic contender. It is mature though and well understood.
- Swing – going back to Swing is probably not an option, too much time has passed. Because its integrated with the JDK anything needs to go into the JVM and thru Oracle.
- QT – I used to really like QT back in my C++ days. It since added some things but ever since the Nokia purchase it was mostly stuck in place. Adding to that the fact that most of the code base is in C++ makes this a non-started for most Java developers.
- Native – this is actually something we are considering for Codename Ones desktop port. Just calling the OS native API’s directly using a native to Java mapping API. For Codename One this is pretty simple since we can use Open GL and very few peers but I don’t think this will be useful for Java developers as a whole.
- HTML5 – I think that JavaScript has a huge advantage when it comes to HTML. If HTML or browsers are the dominant players then why use Java? JavaScript already has the traction & toolkits in the HTML world and Java seems alien there.
- DukeScript/TeaVM/GWT – I really like all of these and the ability to integrate with HTML is powerful, but I think focusing everything on these tools could ultimately relegate Java to a coffeescript substitute which seems like a demotion.
- Android – like Codename One Android wasn’t designed for the desktop. But unlike us its being adapted to the desktop (replacing Chrome OS according to rumors). Its a huge, complex and pretty complete API missing a few key features but its still pretty powerful. The only problem is that this would require quite a bit of effort both in the porting effort and in adding desktop “concepts” to the API (Windows etc.) which was very much mapped to mobile.
How did we get here?
This section is probably redundant for most readers but after writing everything above it occurred to me that a fresh Java developer reading my huge rant will have very little historical context. Luckily I can tell recite the history rather easily as I had a front row seat working at Sun Microsystem during the peek of Java FX and at Oracle as it failed to materialize.
Java launched with AWT which was a pretty problematic “rushed to market” GUI API. Sun wanted to improve AWT and replace it with Swing unfortunately at that time Netscape (the leading browser vendor by a good margin) had standardized on Java 1.1 and Microsoft was also stuck there.
So Swing was developed with compromises designed for it to work within the browsers who were the main users of Java at that time. This bit of history is important since it punctuates the problems in FX perfectly. 10 years or so ago Chris Oliver (a Sun engineer) introduced a rather cool scripting language he wrote and it gained some traction within Sun. At that time Swing was popular with the enterprise but slowly losing ground to Flash in the consumer market.
The managers at Sun decided to promote the idea and placed a lot of effort, resources into this new language which was eventually christened as JavaFX Script. A lot of developer resources were removed from Swing and placed into the JavaFX script project and a lot of promises were made to developers. I actually helped some of the related projects such as the mobile phone ports etc.
There were many problems with JavaFX Script and they were further compounded by Sun’s troubles and notoriously loose management style. Swing was declining rapidly as Oracle purchased Sun. Oracle killed JavaFX Script but liked a lot of the API ideas behind it so they re-targeted the JavaFX effort as a Java based API. Generally a good idea, but in a typical corporate fashion everyone who used JavaFX Script had to port their apps at once to the new JavaFX or be stuck without the ability to download the VM (they later reversed that decision but its not the best way to treat early adapters).
The new JavaFX API took years to materialize and for quite a while wasn’t even open or properly integrated in the JDK. Its integration is partial to this day and its still not a part of Open JDK (which is important on Linux).
When the JavaFX team was assembled and grew they made an important decision that came back to haunt them: Don’t repeat the mistakes of Swing/AWT – build a clean API unburdened by legacy. Unfortunately, being a product of a major corporation in the developed world they needed to support a lot of things (e.g. accessability) and so a huge amount of code needed to be written from scratch.
So the team created a well designed API but there was no decent migration path to Swing developers and to some degree the path from Swing problematic to this day (despite many improvements). The API is huge but still incomplete at some parts because the required breadth for such an API. In the meantime Swing developers who got no real updates for years mostly evaporated to other platforms and now we have Swing and FX one of which is outdated and the other brand spanking new but has no real traction.
I think the biggest lesson from JavaFX is to always “think small” and release often. Trying to build a complete solution from day one rarely works even if you have the full set of resources that Sun/Oracle were able to wield. I would argue that all the problems in JavaFX are a result of mismanagement.
Final Word
One of the things I hated the most about Google under Larry Page was the Spring cleaning, since Android Google has failed to create anything that enjoyed that level of traction. That was not due to lack of trying, it was due to lack of commitment to anything. Most people don’t remember this but Android was a failure when it was initially released (G1) and the iPhone had a very small niche following (relatively to the mobile market as a whole). Both companies stayed the course and invested in the product/partnerships while slowly iterating on the product. This took money, time and commitment which is pretty hard to do.
Unfortunately, looking at the current state of JavaFX and Oracles backing of it. Its pretty obvious that it was already moved to maintenence mode and won’t get the resource commitment it needs to grow. I think we might be better off moving it aside and allowing other technologies to rise to prominence. Even if you disagree with that opinion I hope we can all agree that there is a serious problem here. To me the problem is mostly with students picking up JavaFX either thru universities or online courses. We might as well teach them COBOL, there are jobs writing COBOL too.
With the current state of JavaFX and the lack of any contender to occupy its space (which is currently not officially vacant) I get a sense that we might be better off with nothing. At least then we’d have a big “vacancy” sign in our virtual front yard where our desktop API should reside. This will let one of the options I listed above (or something brand new) occupy that spot… Maybe it will trigger someone at Oracle to finally give JavaFX the resources needed to turn it into a viable tool but knowing Oracle… I’m not holding my breath.
| Reference: | Should Oracle Spring Clean JavaFX? from our JCG partner Shai Almog at the Codename One blog. |
Ok. Take a simple example. I’m writing a small Java financial library for option pricing and I need a nice UI witch charts so that I can play with my library and visually see what numbers are being produced at different input scenarios. This is not a production code that my customers will be using. The ultimate end-user product might have some kind of REST backend with HTML5 frontend that will take an army of visual and UX designers and developers to create. What choices do I have while I’m on my own? I don’t see anything but JavaFX in… Read more »
That’s actually pretty much what I said.
There is no alternative for JavaFX and we DO need a decent Java desktop development environment. Unfortunately, its clear that Oracle has relegated JavaFX to maintenance mode (like Swing and AWT before it) and that it has no real community so to speak.
So what I’m saying is that we need to start thinking about alternatives before its too late. We should also be mindful on how we promote Java/JavaFX in a way that isn’t misleading.
You say JavaFX is not yet part of OpenJDK. Yet there is this page:
https://wiki.openjdk.java.net/display/OpenJFX/Main
“OpenJFX is free software, licensed under the GPL with the class path exception, just as OpenJDK”
What is it missing?
The open JDK distribution shipped by Linux vendors doesn’t include FX normally. They don’t care about it as much since companies like Redhat focus on server software.
Another big problem is that initially JFX was a separate product and when it got bundled into the JDK/JRE it was done in a way that was counter intuitive where you had to add another jar to your complex classpath logic (rather than just adding it to rt.jar) so some things cause issues e.g. I have an issue with javafxpackager on Windows that doesn’t properly package FX into the release bundle.
I found something like that mentioned, although it looks like openjfx is now available as a separate package, although I don’t remember having to install it. I have NetBeans, though, and I might have downloaded the bundle including Java8 with JFX 8. Given that OpenJFX is there in OpenJDK, and there _is_ a community contributing a steady stream of commits, it looks to me like it’s the option with the greatest headstart (apart from SWT which I don’t like either, and Swing which may be showing its age, but is still doing its job and keeping me off the streets).… Read more »
I’m guessing its because you used NetBeans but I haven’t used Linux on the desktop in quite a while. Since we need to do iOS native code for Codename One I have a Mac (the joke is that we have Macs so you don’t have to). I didn’t say Oracle isn’t moving Java forward. What I did say is that they are moving Java, just not JavaFX and don’t believe in it enough to even use it in their own products. Community contribution to JavaFX is a red herring, its a huge code base. As a guy who ran an… Read more »
Hmmm nice, I took a time to know more about Java FX in the this (Carnival Holiday- Brazil) and it is really awesome, Oracle should invest a lot of money on it.
I spent a LOT of time looking for a good GUI and a good language. A good language to me needs to be concise, high-level, curly-braces, performant, and have a good GUI with a future. Java now has all of those perhaps without the last (a future). As far as I could determine, the only good GUIs (with a future) from my perspective were in using CSharp or JFX. I chose JFX partly to be cross-platform, but it sounds as though that is not the case. I thought it had to have a future because a) it is a good… Read more »
I don’t think that’s the problem. Android uses XML but also allows Java code and didn’t suffer from the same fate. I think there are technical problems with Java FX but they mostly relate to the fact that the transition path from Swing is so broken no major public app has taken it on. Without a base to hold the fort it’s really hard to push a technology. E.g. Both Java (during the Applet days) and JavaScript climbed to UI awareness on top of HTML which lacked dynamic UI’s. I think you will be worse off with C# as reaching… Read more »
Java Fx is not dead, i used it a lot. Oracle wont support it in Java 11 , but who cares, now Amazon support Java 8 and it means they would support Java FX!
Here the proof http://www.javacodegeeks.com/2015/11/should-oracle-spring-clean-javafx.html#comment-96975