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:

Launch

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.

Future?

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.

12 thoughts on “JavaFX… it does have a future

  1. I agree, browser based technologies and Java are not the same animal. The browser can only do so much and acts as a great leveler and diminishes what can actually be done. Java is able to deliver true applications via Webstart and should focus on this unique and powerful ability.

    Java has the means to reverse what has become the conventional wisdom of using a browser for everything and instead set developers and users free again. What we all should be doing is developing applications that have their own network services built in and a browser component if one is needed. In other words the browser becomes the component and modular applications rule the web.

    I thought that this was what Sun was delivering via the combination of Java, JavaFX and JWebpane. I hope this is still the path being taken because obviously it is superior to catering to a handful of browsers who take years to provide their compromising and unrobust so called browser standards.

    It has been said that a double minded man is unstable in all his ways and this is what Java is if it does not fulfill its destiny and return the web to its correct posture.

  2. The browser is a platform; the Java virtual machine is another platform. There is no need to combine the two.

    sure. I talked about it 3 years ago. Adobe understand it too. Adobe split the Flash to Flex (GUI only) and AIR (heavy apps).

    Managers from Sun doesn’t understand it.

  3. Sounds great. Let us know when Java Web Start really works flawlessly on all platforms.;)

    It sure would be nice to see Java(FX) applets work properly on the Mac, though.

  4. JavaFX maybe has a future as a niche product in the enterprise space, that’s it. Nobody cared about it when it was released, after years it is still not there and still nobody cares about it.

    The JVM is a platform, I agree. JavaFX is hmm I don’t know. What is it? Not Swing 2.0 which many hoped for, not a Flash/Flex competitor, no IDE integration (please don’t mention the rudimentary support in NetBeans), no Designer Tool, and not even working on all platforms => so JavaFX is literally nothing (to care about). The best way I would describe JavaFX is … a showcase or a prototype.

    I really hope the developers had fun to create JavaFx and learned something from it because so that all the wasted money and working years weren’t for nothing.

  5. The problem with Webstart is that it is suffering from bad marketing – like most stuff from Sun. Webstart exists for several years – yet almost no one knows it. Now compare that to Adobe AIR. It’s a rather fresh technology and is still missing a lot of essential features that Webstart is offering since a long time. However there are already quite a lot of very popular AIR applications around like TweetDeck or Ebay Desktop.

    I don’t know any popular Webstart application though.

  6. Here’s why I think it hasn’t caught on.

    In firefox, I click LAUNCH. What do I get?
    A popup asking if I want to download the JNLP. Then a download window. Then a popup when its done. Then a popup asking if I want to update FX. Then a popup asking if I trust the publisher. Then a windows security popup.
    THEN I finally get to see and use the application.

    Is that OK for an enterprise application on an intranet? Yes.
    I can just hit OK to everything, or maybe my sysadmin has the defaults set that it doesn’t ask.

    But is all that OK for a public kiosk running at an airport, a hotel, or a library? No. I bet that a non-admin semi-locked down browser won’t run that app. And if I can’t use your hotel booking app from an airport kiosk… game over.

    I think these browser->framework limitations is what excludes FX use on most public facing sites.

  7. I think the author finally has it right. I want my apps out of the browser. But I want an easy way to distribute apps thru the browser. JavaFX Java is a good way to do that universally. I think the AIR project from Adobe is just a counter punch against JavaFX making aim at Flash. AIR might be OK for lightweight apps.

  8. Our company has an AIR business app – of the breed that the author has designated a target market for JavaFX.

    We also do Flex apps in the browser so to do a richer desktop app with certain capabilities not possible or advisable for browser software, we decided to go with AIR – seemed naturally complimentary to the Flex skill sets we’d cultivated.

    However, our app needed to establish a local socket listener and to launch native applications. We also needed to keep Java in the mix in order to run some legacy software that is Java based.

    We used Merapi to bridge Java and AIR. The Java side provided the missing features that the AIR app needed. To the user our app has an AIR gui but behind the scenes is tapping Java.

    The author’s case would suggest that JavaFX alone could have been the basis for building this app.

    However, now AIR 2.0 has added features for establishing socket listeners and the ability to launch native applications.

    So we’ll be upgrading the AIR app to 2.0 and moving those functionalities from Java back over into AIR to where we only need to keep Java around for running the legacy software. Once we get all that legacy software re-written to Flex, then we can jettison the Java presence in this equation altogether.

    So we’re not going to adopt JavaFX even though we have software that falls into the category outlined by the author. We’ll keep using Java in the middle-tier, of course.

  9. Once Project JigSaw – if ever of course – comes into place it should have a tremendous impact on performance. Just like it is for flex/flash now.

    Probably JavaOne will shed some light on this.

  10. I recall running Jake (Quake in Java) through WebStart a few years back – it was an impressive experience, downloading and running in seconds.

    I agree that WebStart has been really ‘undersold’ by Sun ( then again, most non-Enterprise desktop applications I use now auto-update, delivered via the internet – the ‘deployment problem’ has been largely solved in the consumer space).

    I also agree that in-house apps, running in a managed environment, can use whatever technology they like. This is an area that Curl has been targeting (enterprise RIA).

    What I would be interested in is why I would use JavaFX, specifically, over competing technologies. What are it’s explicit strengths over Flex or Silverlight?

    My other concern is whether it has momentum – i.e. compared to Flex, Silverlight or the iOS SDK, JavaFX has moved at a relatively sedate pace.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s