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.

Published by

8 responses to “Java on the client… again.”

  1. Maybe using anonymous inner classes with anonymous inner constructors, combines with the final variable change that will be part of closures, declarative programming in Java is solvable:

    new Class1() {{
    property1 = value1;
    property2 = new Class2() {{
    property3 = value3;

  2. I’m still interested in JavaFX since I prototyped an interactive vector graphics application with tens of thousands, and JavaFX was orders of magnitude faster than HTML 5 canvas or SVG or CSS based versions. The technology is hot, it just needs to be sold properly. However, I can’t make the case for going with something that’s a dead end. Let’s hope Oracle keeps up their promise.

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

  4. […] Max Katz has blogged about Java on the client… again. […]

  5. Well, the complain of Mr. Fain reveals that Java is complicated to install? Well I would say anyone that installs Java by itself on Windows should know that there is an uninstaller and at least should have heard the word “registry” before. I think it reveals more about Mr. Fain.

    I don’t think the question is how easy it is to install Java, but how easy it is to install an Java Application (users shouldn’t have to do it and developers should know what they do).
    On Mac it was dead easy and with a little work Apps looks native. We’ll see what happens if the JDK doesn’t come from Apple anymore

    On Windows use things like exe4j and native installers and include your own runtime. This has the advantage of making sure always the best fitting Java (e.g. make sure you have a server VM)

    On Linux, write a little shell script or use izPack for installation and package mangement should care for the rest or write some deb and rpm and so on.


  6. Fain is an entertaining, and often knowledgeable guy, but he has an enormous, vested interest in the competition. He went the full Adobe Flash route and since his living depends on it, finds all sorts of reasons to bag Java. I remember him complaining about generics being too complicated. You pretty much have to stop listening to the guy after something like that don’t you?

    Still. he has a point, for the lazy programmer, Java deployment has always been a headache. If you take a little time, you can get a nice native Windows executable built with a legally pared-down JRE under 9mb. It shouldn’t be as hard as it is, but if it’s the hardest thing you encounter on your projects, then I envy you!

    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.

    Good luck.


  7. @Alex: thanks for your comments. Fain has definitely vested a lot into Flex but on the server side, it’s still Java for them. I think Flash is still pretty safe on the desktop but I don’t see anything happening on the mobile for them. You either go with the native platform, or HTML5.

  8. […] Alex posted this comment on Java on the client…again post (I’m only quoting Alex’s last paragraph), this […]

Leave a Reply

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

You are commenting using your 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.