JavaFX, backwards compatibility, and the path forward

JavaFX at JavaOne impressed me. It is the first time I saw how things could come together to allow for the easy development of applications with both enterprise and consumer user interfaces alike. The combination of the Caspian look and feel, the components, and the team sold me a compelling package. To be clear, JavaFX isn’t ready to be used in many circumstances, as the number of components is too bare, but I am satisfied that this will be rectified in the coming months.

This being the case, and given that JavaFX has been blogged to death, I want to instead cover my opinion on how I believe JavaFX should proceed. I discussed this with a few people from Sun, and I wanted to get the pulse of the (JavaFX) nation on this issue. Let’s be clear – Sun read blogs where there is discussion. I know for a fact the Swing 2.0 discussion from a while ago was heavily discussed internally. I would very much like to see what kind of discussion we get out of this post.

The general question is which path should the JavaFX API take ? Anyone who knows me knows that I like clean APIs, simply for the sake of code cleanliness. You should therefore be able to easily work out my preference ๐Ÿ™‚ The options are below, but if you have any other suggestions, please post a comment.

Option 1: Evolve the API over a number of releases, but never remove methods

As demoed in James Gosling’s Toy Show, there are now apps out there using JavaFX, and JavaFX is a publicly available API with a lot of marketing behind it. There are books in production and already released that explain the API as it currently is. To set the API in stone now would give people more certainty that they should start to commit to JavaFX in their systems. This doesn’t stop the API from growing, or for old methods to be deprecated. This is what we have in most API’s – and it is possible that the end result is a hugely convoluted API (need I do the *cough*Swing*cough* thing, or was it too obvious anyway?).

Option 2: Clearly state the API is undergoing change, but promise API stability for a future release

This is what I call the ‘Google Collections’ approach, as it is what Google have done with their collections API. In this approach, Google has been very, very clear that their upcoming 1.0 release will be a 100% stable API that will not change. They have also been very, very clear that releases leading up to the 1.0 release will potentially have huge API changes. The benefit of this approach is that when 1.0 is released, the public can be certain of a completely stable, and clean / polished API. The downside of course is that early adopters are burnt on releases.

My preference is for the later. I want a clean API that is going to last for a long time. I want to see Sun publicly announce a roadmap for the next x months which will culminate in a stable, rock solid, and clean API that will last for the foreseeable future. As things stand, there is no clarity on what will happen next with the JavaFX API, and I think that is at least partially because the public has not yet spoken. If we don’t speak up soon, it’ll be too late.


26 thoughts on “JavaFX, backwards compatibility, and the path forward”

  1. I’m an early adopter of JavaFX, with TwitterFX being what I consider a significant JavaFX based application in terms of scale.

    The recent changes from JavaFX 1.1 to 1.2 have given me alot of work to do with hundreds of compile errors, removed API’s, changed behavior making me rework my app.

    But I can see the improvements in the API in terms of greater consistency and more power.

    So despite the pain, I prefer the breaking change as long as we’re always moving toward a simpler outcome.

    This language and runtime is too young for us to be tied to the oversights of the (very recent) past.

    And I want a basic HTML rendering component. Now. :O)

  2. I definitely lean towards the second. There is nothing more frustrating that bumping into some API only to find out later how dangerous or bad it is; but it was kept for backwards compatibility.

    In general I’m happy to hear that JavaFX seems to be growing up right, but do think that there is still a place for a “Swing 2”?

    And more generally do think JavaFX could ever be used to build the GUI of an app that is Microsoft Office?

    1. @Tim Vance: Good to hear from you again ๐Ÿ™‚ I think JavaFX is some way off of making it easy to build an application such as MS Office, but I can certainly see it becoming more possible in the coming months/years.

      Swing 1.5/2.0 is growing by way of the Swing Generics project.

      Thanks for your response. I agree that having cruft in your API is not good. I have word from high sources that Richard Bair, in charge of the JavaFX API, is the king of API, and it seems he is putting considerable consideration towards the API to prevent introducing cruft.

  3. I’m definately in favor of continuously evolving and cleaning up the API. Once JFX has a more or less complete RIA offering and theres significant adoption we can revisit this. The iphone sdk had breaking changes as well…

  4. I’m surprised that no one will talk about the elephant in the room. Namely, that JavaFX is not redistributable. Any apps you make must link dynamically to Sun’s JNLP for deployment. It’s in the license, and talking to some insider’s at Sun a few months back, there is no immediate plan to change this. This renders JavaFX completely useless for us serious desktop developers who must distribute complete work with native installers. This betrays a jaw-dropping lack of direction from Sun.

    1. Alex,

      I’m sorry but I really don’t understand what you’re saying. The elephant in the room is not visible to me as I’ve not heard of this JNLP issue you mention. Can you please clarify what you are saying?

      — Jonathan

      1. Each JavaFX based app’s JNLP file refers to the URL of the underlying JavaFX runtime as a dependancy.

        This runtime is hosted on Sun’s servers.

        On one hand it means that there is leveraging in relation to getting the runtime on computer’s (i.e. another person’s app helps bootstrap your with caching the runtime). But if the user is offline or behind a firewall, this may be an issue.

        1. Many of us have no interest in writing WebStart apps. I work on one fulltime and it’s still a deployment nightmare. Or Applets. Users hate them and they still crash the browser despite Sun’s claims on 1.610. I speak from personal experience. So, those of us who want to write desktop apps or Java Swing RIAs cannot use JavaFX in any way.

  5. This is my third iteration at updating and fixing several large codebases based on changes in the JavaFX APIs, and while there was a lot of change to deal with (see, most of it was isolated to the new or less stable portions of the codebase (notably Controls, Layouts, and Stylesheets).

    What I think would help greatly to make sure that the released API is going to serve the community well would be to have a public beta prior to launch. This would give the entire community a chance to give feedback on new and evolving APIs before they get set in stone.

    1. @Stephen Chin: I agree with the public beta – this is what I was asking for in option two. It would be nice to see this approach considered and discussed further. Then we all have a certain timeframe to thrash the API and make sure it meets the expectations and needs of the public. Once the beta is complete, we can’t complain about the API any further ๐Ÿ™‚

      Thanks for the feedback!

  6. Refer to the JavaFX license:

    5. Restrictions.

    (a) The copies of Software provided to you under this Agreement are licensed, not sold, to you by Sun. Sun reserves all rights not expressly granted. (b) You may make a single archival copy of Software, but otherwise may not copy, modify, or DISTRIBUTE Software.

  7. I want to integrate FX into my projects. But as long as they keep breaking stuff and making the binary interop a moving target, I cannot spend my ever shrinking free time integrating it. So whether they get other issues right or not doesn’t matter, I won’t really be interested in it enough to use it until there is some public commitment that binary interop will become more stable.

  8. Oh, and also, what Alex said. Until distribution is fixed as well I cannot even begin to consider using it professionally. The environments I deploy to are usually totally disconnected from the internet at large, often disconnected from any network at all at runtime. FX needs some easing of the license WRT redistribution.

  9. I still believe that the biggest issue with jfx is with it’s friendliness with swing. It does not exist. I cannot understand why it is not possible to create jfx-widgets that are useable in swing. It might be that I’m to ignorant on the subject but then someone, please explain it to me. ๐Ÿ™‚

    Imagine how much wider the adoption would be if both swingers and fx:ers could create widgets in jfx and share their work. JavaFX would quickly get a huge number of “part time adopters” in the swing community. These people would create jfx code used in their existing swing projects and share this code with the full time (early) adopters.

    Also, why learn javafx as a swing developer? Why not learn Flex/Air or Silverlight? One argument is because it runs on the java platform. A much (much) better argument is that it can be used in existing java/swing software. Only problem is that the better argument is not true. I was hoping Amy Fowler would show us this in the extream gui makeover, but sadly she didn’t. At least not in a way that would be easy in large scale desktop applications.

    So, both Adobe and Microsofts solutions are still open to me when starting new projects. They wouldn’t be if I already knew JavaFX. I would know JavaFX if I could use it in my existing projects. This is what I want in the future for JavaFX!

  10. I don’t have too much to add to what have already been said. I agree that JavaFX needs to be “more stable” to have greater adoption. In my case, I haven’t spent as much effort as I wanted in FEST-JavaFX (library for functional testing of JavaFX UIs) because I was in a “wait and see” mode, waiting for JavaFX to stabilize. I sincerely hope that starting with JavaFX 1.2 this will be case, so I can continue my work on FEST.


  11. Whenever there’s a change, breaking something or not, the faster the feedback loop the better. That’s especially important in a rapid changing and not yet mature environment. That’s why i’d recommend two obvious possibilities that we have discussed before: 1) nightly builds of the runtime 2) open sourcing (which would also solve the redistribution problem).

    I should probably note that usually in most licensing terms, if you’re doing in-house apps, you can deploy it to your colleagues however you want, as this is not considered distribution per se, then again IANAL. I thought this was worth mentioning since most of the web apps in the world are behind firewalls in intranets, this web start deployment requirement should have no effect on your end if you’re in this situation, and you could do it in javafx.

    On a less technical aspect, once again more communication could be helpful, since javafx developers right now are kept in the dark as of what’s going to happen over the next releases as there is no roadmap, and JIRA is mostly secret.

    I’ve said before i think an easier path of migration would be a fully transparent and perfect integration with java/swing. I still think it’s true, but i’m not sure it would be for the right people. Java/swing developers don’t seem to be the primary target demographic: sun describes them as “web scripters” (aka flex/silverlight developers ?), which might seem odd at first. But, out of all the java/swing developers in the world, i’m not sure there’s a big enough percentage interested in effects, animations or better ux, or needing them. This is exactly the opposite for flash where it’s the “only” thing it does, and they needed the opposite enterprisey stuff, like buttons and all. So while i think it would lower the barrier to entry i don’t know if many more people would jump onbard for certain. The java/swing developers interested enough can certainly try and learn javafx on the side, put it to use in new projects and not existing swing apps.


  12. Stable API’s within a major release (1.x), so during patches and minor updates.

    Break API once every two years when release a new major release (x.0) Unfortunately that point has not been reached yet with JFX.

  13. Three big problems:

    – redistribution issues, as described above

    – continued fixation on JavaFX script (which is not going to win any hearts or minds (or, perhaps not *my* heart or mind) vs. any of the other fantastic JVM languages being developed in the commons, e.g. clojure, jruby, etc)

    – no swing interop

    All three of these issues are essentially showstoppers. Almost worse than that is: what’s javafx’s raison d’รชtre given swing + any decent non-Java JVM language. For what we do, I’ve not seen anything compelling, and I think it’s clear that there are many others with the same perspective.

  14. I definitely vote for option two. JavaFX Script and the platform are still evolving, and many pieces are still not there yet. Plus the installed is almost non existent. It would therefore be very unwise a this point in time to shackle the platform down with backward incompatibility restrictions. For instance, I would really like to see added to the language, and/or the API some nifty declarative syntax to support the actor based concurrency model, instead of the thread based model that we have right now. I would like for the language to offer a solution to the concurrency problem as elegant as its solution to the binding problem. And I believe the most optimal way to do this is if you are not tied down backward incompatibility constraints.

    1. Brian Goetz and I have talked about concurrency on several occasions, and actually we’ve been quite careful not to paint ourselves into a corner over concurrency. I don’t know if we’ll have it in the next release, or the one following, but we definitely have some plans cooking for concurrency. One thing we are definitely NOT going to do is expose the full threading model to the user — there won’t be semaphores, locks, concurrent queues, etc. If you need those, dip into Java (and there will be API for guiding down this path as well). From FX script, it’ll be dead simple, and Task based. At least, that’s the plan ๐Ÿ™‚

      1. Thanks Richard for the reply. About concurrency, here’s what I think: JavaFX with its elegant, language level binding support, brought the dataflow programming model to the mainstream and to the average developer. The binding support allowed us developers to model state changes in running applications as a (directed?) graph of data flowing between operations. Which, according to wikipedia is what dataflow programming model is all about. As such, I believe the actor based concurrency model is the perfect fit for this type of programming as it allows us to seamlessly blend the dataflow model, with the concurrency model. Imagine for instance being able to bind on the results of a set of actors before pushing the data downstream (Software Transactional Memory anyone?). How powerful can that be?

  15. I believe option #2 is fine, JavaFX is still in the early adopters phase (after +2 years no less) so getting the API right is a Good Thing. However as @shemnon mentioned makes the job harder. But what really makes JavaFX a fish out of water is its distribution story, until it is fixed JavaFX apps must be tethered to a network connection, many enterprise apps do not allow that easily.

  16. Like Stephen and lqd mentioned, a faster feedback loop is necessary:

    1. Nightly builds
    2. Public betas
    3. Better versioning numbers: 1.2 was a major change (could be subjective,) probably labeling “2.0” would have been better


  17. I agree with Steven, even if I haven’t done yet a real application, mostly small test scripts.
    Lot of stuff was broken with Java 1.2, but I don’t mind rewriting (at this point), because the changes are in the right direction: the Control/Skin becoming Control/Skin/Behavior is a good thing, improving separation of concerns.
    At least at the debuts, I prefer breaking changes, they will be stuck when people will start writing big applications…

  18. How many of these problems are being caused by JavaFX abandoning the JCP with JavaFX and Jigsaw (at least the open aspects) and pretty much handling them as some secretive Skunkworks project?

    Just ask @lqd about the sudden removal of a lot of the animation parts of the Scenario APIs in JFX 1.2. @lqd – If you remember I did warn you about that ‘implementation detail’ terminology. I do wonder when we’re going to see these new contribution servers/services that’ll be needed for contributors to work on OpenJDK designs/specs/code at the same level as Sun staff. Larry didnt seem to talk much about their commitments towards openness (but then I wasn’t there).

    On the other hand JFX is a work-in-progress pieces of the puzzle are still being fitted into each release, as such the APIs are taking shape as needed. They’re working in a very compressed timescale with apparently very tight developer resources (compared to adobe/microsoft) so corners needed to be cut. APIs in one draft are rarely ‘perfect’ nor efficient so they’re possibly keeping the implementation private to prevent any ongoing curn upsetting developers too much. The JNLP distribution at least introduces a kind of versioning dependency system that allows them to change APIs and limit the breakages to code needing porting between two versions. I take it javafx1.0, 1.1 examples still run OK? (will they always?)

    I’ve always questioned who the developer market for JavaFX really is.. Given the increased production values inherent with dynamic effects and animations I think its better suited to interaction designers and new media producers not your typical Java/Swing code monkeys. I doubt they’ll be cutting any code nor working at the API level.. it’s way too low for most creative endeavours. If JavaFX stays kinda half & half you need both the deep Java2D/EDT threading knowledge and great creative skills it’ll never get much momentum (or @Kirillcool will get very rich). Currently we dont see these creative designers and Java/JavaFX crowds mix and I wonder if simply building JavaFX is enough to start changing that?

    What I’m struggling with is the collapse of demand for desktop apps (and Swing developers and a even greater lack of demand/jobs for JavaFX. As a client-side Java developer I feel left in a very exposed position. Swing skills don’t translate to the HTML5/Ajax/JS/HTML/CSS domain that replaced them. Nor is it clear Swing coding skillz translate all that well to JavaFX either if you think it’ll be the web and new media production companies to be the ones to take it forward. Designers with skills in Flash/After Effects/Interaction Design etc.. Are Swing devs washed up? how do you survive the gap years? Suggestions on a postcard.

  19. Thanks for starting this thread, Jonathan. Yes, we greatly appreciate the discussion.

Comments are closed.