JavaFX 2.0 – no Mac or Linux support?

In early February JavaFX 2.0 preview was released to partners and beta testers. A number of articles and blogs appeared demonstrating the new JavaFX 2.0 API (here, here and here). In general the feedback was very good and everyone is impressed with JavaFX 2.0. I think everyone likes that idea that plain Java again is used to build the UI.

Something that no one has mentioned and surprises me very much is that JavaFX 2.0 will only be supported on Windows, at least at first, according to this interview with Richard Bair, the architect for client software at Oracle. This basically means that you most likely can’t develop or run a JavaFX application on either Mac or Linux. I think it’s a huge problem and will make JavaFX adoption extremely challenging (again).

Java on the client, Flash, mobile

Reader Alex posted this comment on my Java on the client…again post (I’m only quoting Alex’s last paragraph). This is a very interesting part:

For good or ill, the debate is becoming moot as mobile takes over. The future of “client-side” Java is most likely on Android. What remains on the desktop will either be in the browser or split among increasingly irrelevant technologies like Swing, .NET, and Flash. The degree to which Sun/Oracle has screwed up Swing at this point is truly epic.

I think Flash is safe on the desktop for now. I mean, we used Flash for Tiggr prototypes simply because it was faster for us to get where we wanted today. (We will be looking at HTML5 sometime this year, though.) However, moving forward I think there will be more and more pressure on Flash. I know that for some applications, it’s still much simpler or even “better” to use Flash, but, if HTML5, JavaScript and CSS can be used in 90% of cases, why use Flash? It’s interesting, a few years ago I thought that JavaFX was the challenge to Flash. I was wrong. Hey, you never know, maybe JavaFX 2.0 will finally turn out to be that technology.

On mobile, the situation is very different. I just don’t see Flash going anywhere in that area today. Flash on mobile kind of feels like JavaFX on the desktop – people talk about it, but no one uses it. The big battle between Apple and Adobe last year – does anyone remember it today? Does anyone miss Flash on mobile devices? I have been using Android for the past six months, and not once did I miss Flash. Just once, I accessed a news page with embedded Flash video.

With iOS being the dominant platform, most content providers adapted by producing either a native app or a Web app (HTML). There is a huge benefit to creating a Web app. You create one app and cover all the platforms: iOS, Android, BlackBerry, Windows Phone 7, and webOS. BlackBerry is saying their devices support (or will support) Flash, but it’s probably just a gesture to show that they are different from iOS as they continue losing the battle against iOS and Android.

With a large number of smartphones and tablets coming out this year, it will be interesting to see how this develops. Perhaps an update in January 2012. reply to: Java on the client… again.

Cameron McKenzie from posted a reply and summary to Yakov’s and my blog post: Java on the client…again.

Java on the client… again.

Yakov Fain blogged that Java on the client has no chance succeeding with the current complicated installation process. Unfortunately I agree. But, I also think there is even a bigger and very closely related problem, launching Java client applications. I blogged about it here. Launching Java applications on the client could be very challenging.

With JavaFX 2.0 undergoing dramatic changes (JavaFX script is dropped), we are going to start looking early next year how to update Exadel JavaFX Plug-in for Eclipse and Exadel Flamingo to work with new JavaFX. With JavaFX script being dropped, applications will be developed using Java API. I get a feeling that a few years ago it was popular to use declarative languages to create user interfaces and now we are going back to using Java. Maybe GWT has something to do with that. Two things must happen for JavaFX or Java on the client to succeed: easy virtual machine install and easy deployment. Even with major, and I believe positive changes in JavaFX 2.0, without the two things I mentioned above, it’s going to lose the battle against plug-in free browser applications.

I still find one thing very interesting. With JavaFX 1.x out for about three years during which it didn’t produce any real applications and JavaFX 2.0 is still in development (and with somewhat unclear future), you still get JavaFX presented at various conferences. Just last month at Devoxx, JavaFX was covered by 4-5 sessions. The community is strong. At the same time, you never hear HTML5 vs Java client, it’s always against Flash. So again, client Java is kind of there but also not there.

What is going to happen with Exadel JavaFX Plug-in for Eclipse?

JavaFX 2.0 will use Java APIs instead of JavaFX script to build user interfaces. If you are curious what’s going happen with Exadel JavaFX Plug-in for Eclipse, I blogged about it in JavaOne 2010: what happened with JavaFX (part 2) post. Here is the excerpt on the plug-in (and Flamingo):

How was Exadel involved with JavaFX? In two ways. First, we had the Exadel JavaFX Plug-in for Eclipse and Exadel Flamingo: both open source. Flamingo allows connecting JavaFX to server-side technologies such as Java EE 6, Seam, and Spring. Flamingo also supports Flex, Swing, and JavaME connecting to these same technologies.

What’s going to happen to these products? The most affected product is our JavaFX plug-in for Eclipse. The JavaFX Script editor was one of the main features in the plug-in. With Oracle stopping JavaFX Script development, there is little value for us to continue developing the plug-in. So, as of now it’s on hold. There is some good news. Steve Chin is launching a new project and language called Visage. The language is very closely based on JavaFX script and will need a good Eclipse-based tooling. This is one area where our plug-in could get a new lease on life.

Now to Flamingo. The Flamingo situation is a little better. Once the JavaFX 2.0 API is out, we will quickly update Flamingo to work with the new API. Even today Flamingo works with Swing, so updating it to work with the new API should be simple. Enterprise applications are going to be very important and a framework like Flamingo is needed to easily connect the UI with the enterprise server side. As Amy Fowler said in her blog post A Heartfelt Ramble on Swing & JavaFX: “Oracle sells a lot of applications, and those applications will need great UIs too.”

The latest version of JavaFX Plug-in for Eclipse can be downloaded from

JavaOne 2010: what happened with JavaFX (part 2)

This is part two of my JavaOne 2010 review and thoughts. To read part one, click here.

What happened with JavaFX?

As everyone knows by now, Oracle is making significant changes to JavaFX. Oracle is stopping any further development of JavaFX Script. Instead, it will develop Java APIs which will become a part of JavaFX 2.0 to be released in the second half of 2011. So, instead of using JavaFX Script to develop rich Java applications, you will use the new Java API. If you followed Twitter during JavaOne, many people called it the next Swing or Swing++ or something similar. No matter what you call it, you will be able to open your favorite Java IDE and start creating JavaFX applications.

Oracle is finally making significant changes to the platform which is very good. I blogged about the future of JavaFX in late July and said that Oracle should either start pushing JavaFX hard or just discontinue it (or let the community drive it). I said Oracle had about 6-12 months to do this. I doubt they listened to me, but Oracle is definitely going to push JavaFX, although with significant changes (dropping script) from the state it was in when I blogged. You can view the road map for JavaFX 2.0.
Continue reading “JavaOne 2010: what happened with JavaFX (part 2)”

Interesting writeup-on present and future of JavaFX

Interesting write-up on present and future of JavaFX by Osvaldo Pinali Doederlein. I had two posts on this topic JavaFX… does it have a future? (mentioned by Osvaldo) and JavaFX… it does have a future.

Exadel Flamingo now supports CDI and Bean Validation for JavaFX

Exadel Flamingo now has support for CDI (JSR299) and Bean Validation (JSR303). You can try the features from a nightly build.

The following features are supported so far:

  • Calling CDI bean methods
  • Support for EL (Expression Language). Bind to values and invoke methods with EL in JavaFX
  • CDI conversations
  • Bean Validation (JSR303)

To download a nightly build, go to and click on Nightly builds on the right.

To get started with JavaFX and CDI/Bean Validation, you can look at these examples as reference. The client side code is the same, the only difference is instead of Seam components, you now use CDI beans on the server (and the appropriate annotations).

We are also planning to add CDI events. If there is anything else we should add, please let us know.

RichFaces workshop in Germany

I will be presenting and teaching a RichFaces workshop in Nuremberg, Germany during Herbstcampus conference, September 12 – September 15, 2010.

With the upcoming RichFaces 4 release, the workshop will cover RichFaces version 4. This is a great opportunity to learn standard JSF 2 Ajax features and how RichFaces 4 advanced features, tags, customization and richness add on top of JSF 2. RichFaces 4 is a major upgrade. A lot of core functionality is being rewritten to make RichFaces faster and better. Many components are being rewritten to make them simpler, perform faster and consistent across board.

Get 25% discount by using this URL. Alternatively, you can use this booking code: ceHioRcpiD.

RichFaces workshop (full day)
Sunday, September 12, 2010
More info >>

I also have two general sessions.

Ajax Applications with JSF and the two New RichFaces 4
Monday, September 13, 2010
More info >>

Enterprise Applications with JavaFX and Flamingo
Tuesday, September 14, 2010
More info >>

As a reminder, we are also doing a webinar on September 8, 2010:
Ajax Applications with JSF 2 and the New RichFaces 4
Register >>

JavaFX… it does have a future

In looking back at my JavaFX… does it have a future? posting, my views have been changed by some of the comments made (here and here), in particular about JavaFX vs. Flash/Flex and Java Web Start.

JavaFX and applets

I agree that comparing JavaFX applets vs Flash/Flex is not something we should be doing. Flash applications (deployed inside the browser in a Flash virtual machine) are years ahead of Java applets. It will take years, if at all, for applets to match Flash-like deployment. According to Adobe, Flash is already installed on 99% of Internet-enabled desktops. In case it’s not available, installing Flash is a breeze (plus Google Chrome now ships with Flash player). Flash applications are installed very quickly, work, run smoothly inside the browser, and users are comfortable using such applications.

JavaFX and Java Web Start

On the other hand, deploying JavaFX applications via Java Web Start is an area where JavaFX could be successful and find a niche market.

A JavaFX application started via Java Web Starts runs in its own “Java window” outside the browser. This way the application is still running inside the powerful Java virtual machine, so you get a rich and responsive user interface that is also now browser-independent.

Launching via Java Web Start can be easily done by placing a link to a .jnlp file inside a Web page or even creating an icon on a desktop. Now we get the power of Java but outside the browser. However, the application still acts like a “Web application” since Java Web Start will check for any updates in the application and download them if necessary (like Adobe AIR). This way the user is always be running the latest version of the application.

For example, click here to launch JavaFX Seam Booking application via Java Web Start (note: the .jnlp file is generated in this case). Or click on this nice button:


It launched pretty fast, has its own window, no browser freezing, pretty nice.

Although I don’t see many consumers-facing applications deployed using Java Web Start (even thought it’s possible and some might), the target market is enterprise applications (or Internet business applications) such as customer support applications, rich interactive dashboards, scientific applications, educational applications, and other Intranet-based applications. For example, just replacing all Swing deployments in the enterprise would give JavaFX a huge potential market opportunity.

JavaFX and enterprise

Connecting JavaFX Web Start applications to a server is easily done with the Exadel Flamingo framework. This framework was designed from the ground up to make it simpler to attach rich UIs like JavaFX to back ends like Seam.

Furthermore, a growing requirement is to make Web applications available offline or when there is no Internet connection available. As the platform for JavaFX is the Java virtual machine, the offline feature can be more easily implemented than if the browser were the platform. And, if using the Flamingo framework, it already includes offline features that enable the application to run without an Internet connection and synchronize with the server once the connection is reestablished.


I always believed before that running JavaFX applications inside the browser was the way to go. While it’s still possible (and easily done), I don’t believe that’s the way to go anymore. The browser is a platform; the Java virtual machine is another platform. There is no need to combine the two.