BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Mobile, JavaFX Emphasized at JavaOne Keynote. JavaFX Script is Dropped

Mobile, JavaFX Emphasized at JavaOne Keynote. JavaFX Script is Dropped

Leia em Português

This item in japanese

Bookmarks

At Monday's JavaOne keynote in San Francisco, Oracle EVP Thomas Kurian highlighted Oracle's plans for the Java platform. According to Mr. Kurian, the "three year product road map" had the following major themes:

  1. Optimize Java for new application models that are emerging and for new classes of hardware;
  2. Enhance developer productivity;
  3. Improve performance and scalability on multi-core hardware;
  4. Increase JVM support for multiple development languages.

Mr. Kurian went on to describe some of the concrete initiatives designed to meet these goals. Many of the initiatives covered are already well known and targeted for JDK 7 or later, for example initiatives like:

  1. Projects Coin , Lambda , and Jigsaw;
  2. invokedynamic bytecode instruction to improve performance of dynamic languages;
  3. Fork/join framework.

Other initiatives were slightly less well known like native support for Infiniband networking, 1TB low-pause garbage collection, and removal of the permenent generation from the hotspot VM. Each initiative was mentioned briefly without many details, though Mr. Kurian did direct the audience to online roadmaps for OpenJDK, GlassFish, and NetBeans.

JavaFX, however, was covered in more detail and garnered the strongest crowd response. The JavaFX team gave a demonstration that included the simultaneous streaming of 160 different video feeds that were themselves overlaid on a 3D scene and moved around in 3D space while playing. At one point, one of the videos was shown blown up in a 3D space before splitting into 1,300 (still playing) cubes that fell to the floor like toy blocks.

In addition to emphasizing the performance aspects of JavaFX, the team also explained Oracle's goal to "deliver the best HTML5 and native application experience from a Java programming model." In the future, JavaFX is intended to be a general visual abstraction layer capable of rendering to either a native Java 2d/OpenGL/Hotspot VM stack or to a Javascript/HTML5/Web browser stack from the same API calls. Oracle committed to two new JavaFX releases in 2011 as well as to open sourcing the platform, though it did not give any details on which open source license would be used.

As part of this, Oracle have announced that JavaFX Script will be dropped, and replaced with a new Java API for creating JavaFX applications, that can also be used from alternative languages such as JRuby, Clojure, Scala and Groovy.  A consequence of this is that JavaFX looses the binding support that JavaFX Script provided.  Whilst no solution for this is currently available Stephen Chin and Jonathan Giles suggested in a follow-up presentation (PDF document) that work was bring done to rectify the issue.  A full roadmap is available.

The presentation then gave a nod to server-side programmers by presenting the same details about JEE 6 that InfoQ covered when released in December of last year.

Mr. Kurian then explained that Oracle considered the mobile and embeded space the "new Java frontier" and listed several devices that run Java like Sony Ericsson smart phones, Amazon Kindle, Livescribe smart pens, Cisco VoIP phones, and Java cards. Notably absent was any mention of Google Android.

Finally, before wrapping up with an appearance by Apolo Ohno, Mr. Kurian brought on Dave Moore from BioWare to present an energetic video of the company's game Star Wars: Knights of the Old Republic. The game does not use Java to render any of its graphics or game physics, but it does use GlassFish as a logon server for players in the multi-player world, as well as for other administrative tasks between the web site and the game.

Overall, the key note read like a summary of the past two years in Java and did not reveal much new information. It did, however, give a hint about Oracle's future emphasis on more consumer-oriented technologies like devices and graphics as well as its continued support for developer-centric improvements to the core language.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Wow, dropping JavaFX script is a strange twist!

    by Russell Leggett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Overall, I think it will probably help adoption tremendously to make JavaFX a first class citizen from the other JVM languages. If they needed to drop JavaFX to do it, then it is probably the right move for Oracle. However, (without having really used it) it did seem like a really innovative and elegant language in the UI space, and I'm sure the developers that have actually adopted it will really miss it (especially the binding stuff). I work daily with a framework/language that has binding built into the core, and I can tell you that it would be a game changer to lose it.

    I think the ideal solution would be to keep JavaFX script, but make it easy to use a different language instead, or at least make it easier to interoperate. Perhaps that was just too big of an investment/challenge to accomplish.

  • Re: Wow, dropping JavaFX script is a strange twist!

    by Matt Passell,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm happy to hear it. I just wish the decision had come sooner. I was always surprised, and a bit grumpy, with Sun for not going with an existing JVM language (Groovy?!) when they created JavaFX. Wouldn't it have been nice if all of the effort poured into tooling support for JavaFX Script had instead improved support for an existing language?

  • Re: Wow, dropping JavaFX script is a strange twist!

    by Russell Leggett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I just wonder with FX script gone, at what point will an XML based language take its place? Look at flex and silverlight - they both have an xml based UI syntax including data binding. JavaFX tried to fit the bill by being very declarative and having some very smart features specifically designed for UI development. Adding closures to Java will not be enough to make it feel lightweight and declarative. Groovy or another language might fit the bill, but I guess I see it falling into the same trap as JavaFX. Unless I already use it, I won't want to learn. For whatever reason, XML seems neutral enough and doesn't seem to "count" as another language. I'm curious to see the DSLs people come up with in more flexible languages. I guess we'll see :)

  • Re: Wow, dropping JavaFX script is a strange twist!

    by Luis Espinal,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I just wonder with FX script gone, at what point will an XML based language take its place?


    I hope that never happens. Gimme a real, declarative, non-bulky programming/scripting language over XML anytime. We have suffered of enough XML hell to have yet one more layer added to the top of the monster XML lasagna.

  • Re: Wow, dropping JavaFX script is a strange twist!

    by Steven Sagaert,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Such DSLs already exist. Look at Griffon. Mainly provides a Groovy (as opposed to XML) declarative DSL for Swing but also for other GUI toolkits like GTK+, Pivot (a JavaFX competitor) and even some support for the current JavaFX (or so they claim ;) )

  • goddamit

    by Luis Espinal,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Looking at Chin and Gile's presentation, I wouldn't try to use Java for developing JavaFX applications. It's the same bulking Swing-like semantics of old. I'm not even sure if I would use Java 7 with closures and all for accessing JavaFX facilities.

    The only rational approach for developing JavaFX applications without JavaFX Script now is to use alternative languages like Groovy, JRuby and Jython. JavaFX Script was an excellent language for developing UIs. Dropping it doesn't make much sense, and pitching Java (even Java 7) for accessing it is not a reasonable option. Verbose language constructs for developing UIs is a not go, we have been at it for years, and we know that it simply sucks.

  • Groovy, JRuby cannot really replace JavaFX

    by jean-simon Larochelle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Well at least not for me because those languages are just too slow. Some sort of DSL written with Scala or similar language (running at speed comparable to Java) would be the only option for me. The thing that I liked about JavaFX script was that the syntax unlike Scala was reasonably "Java like" and that because of the speed you could actually write most of your application code in it.
    The least that Oracle should do is OpenSource JavaFX script.

  • Re: Wow, dropping JavaFX script is a strange twist!

    by Russell Leggett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I hope that never happens. Gimme a real, declarative, non-bulky programming/scripting language over XML anytime.


    Yeah, that was basically my point. Just saying that it seems like the defacto way of doing it, especially when the alternative doesn't have a very declarative style. Look at Apache Pivot, GWT 2, as well as probably half a dozen Java swing frameworks that decided XML was less painful than Java. JavaFX was an innovative alternative, but perhaps it was a little too innovative for the masses.

  • Re: Groovy, JRuby cannot really replace JavaFX

    by Luis Espinal,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Well at least not for me because those languages are just too slow. Some sort of DSL written with Scala or similar language (running at speed comparable to Java) would be the only option for me. The thing that I liked about JavaFX script was that the syntax unlike Scala was reasonably "Java like" and that because of the speed you could actually write most of your application code in it.
    The least that Oracle should do is OpenSource JavaFX script.


    I'm not exactly sure I follow the argument of Groovy and JRuby being too slow. Slow for what? Slow for back-end transactions, then maybe. For UI development? I don't think the argument holds water unless the UI is involved with heavy algorithmic computations (as some UI apps I've worked in the past.)

    When it comes to UI development, ease of writing is (usually) more important than raw speed. If we look at how we develop web UIs, we inevitably utilize templates and template languages (velocity, JSTL, haml come to mind) that rely heavily on reflection, not necessarily the fastest of things on the JVM.

    I've done some numbers on my own (nothing utterly scientific mind you), using typical technologies like JSP or velocity and the displaying of data using JSTL or JEXL. I've not found that the lack of raw speed on Groovy and JRuby would actually be a detriment for displaying models on pages written on them.

    Also, problems with Groovy speed are becoming a non-issue now that we have the Groovy++ compiler which pretty much resolves many of the issues previously encountered.

    I'll take Scala over Groovy any day... when the task calls for it. I don't necessarily see evidence that raw computational speed on par to plain ol' Java is an issue when developing UIs and UI front ends.

    Back-end heavy lifting, that's another thing. But for UIs, nope. Sorry I don't see it.

  • Re: Groovy, JRuby cannot really replace JavaFX

    by jean-simon Larochelle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Well I thought I made my argument clear. I did say I liked JavaFX script because:

    you could actually write most of your application code in it

    Not just GUI. Maybe I needed to add that this code includes business logic (including some fairly complicated algorithms) that need to be fast. I think it is a pain if you have to switch language two often.
    I agree with you that Groovy or JRuby are ok for many types of applications. Typical Web apps in particular. I have heard and can understand that Rails and other framework are great for that.
    However, more and more Web technologies are used on the desktop for types of applications where network speed is not the limiting factor. I guess my main point was that JavaFX was not just a language with a nice syntax that can be replaced easily with Groovy or Jruby. Also, patching Groovy by using Groovy++ on top of it does not fit my idea of a good language.
    JavaFX was a nice language fixing many of the warts people complain so much about Java. It was also reasonably fast without having to use other tools on top of it. I think there definitely was a place for it and I will miss it.

  • Re: Groovy, JRuby cannot really replace JavaFX

    by Luis Espinal,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Well I thought I made my argument clear. I did say I liked JavaFX script because:

    you could actually write most of your application code in it

    Not just GUI. Maybe I needed to add that this code includes business logic (including some fairly complicated algorithms) that need to be fast. I think it is a pain if you have to switch language two often.
    I agree with you that Groovy or JRuby are ok for many types of applications. Typical Web apps in particular. I have heard and can understand that Rails and other framework are great for that.
    However, more and more Web technologies are used on the desktop for types of applications where network speed is not the limiting factor. I guess my main point was that JavaFX was not just a language with a nice syntax that can be replaced easily with Groovy or Jruby.


    Ahhhh, ok, I see your (valid) point now.


    Also, patching Groovy by using Groovy++ on top of it does not fit my idea of a good language.


    But that's not so much to do with the language, but the compiler. Aside for a backwards compatible annotation, the language remains the same with no patch at all. It's more a compilation than a language design issue.

    JavaFX was a nice language fixing many of the warts people complain so much about Java. It was also reasonably fast without having to use other tools on top of it. I think there definitely was a place for it and I will miss it.


    I feel the same. I'm not exactly thrilled with JavaFX being dropped. It would be nice if an open source project would come into existence to implement an efficient variant of JavaFX (free of any legal tangles from Oracle.)

  • Re: Groovy, JRuby cannot really replace JavaFX

    by jean-simon Larochelle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I almost agree with your point about compiler. However, since there is right now only one Groovy compiler then the separation between language and compiler (that we have with other languages like C++) does not exist with Groovy. You just don't have any choice. You use THE Groovy compiler and Groovy++ if you want a little more speed. And this is true of other JVM languages (Clojure, ...)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT