We really do need a new rich Internet platform. We need more seamless platforms that work across operating systems and mobile devices. And, in an issue extremely relevant to this site, we need development tools that make it easier for artists of all kinds to create media software and digital artwork and performance tools. The smarter those platforms, the more amazing artwork and live visuals and VJing you’ll see – scroll through the archives of this site or the Processing exhibition for proof. Small as that market may be, it’s my belief that the artistic, cutting-edge output is what will drive the future of media on digital devices. They call it cutting edge for a reason – it’ll be part of something bigger.

The bad news is, wishing for a better platform doesn’t make JavaFX 1.0, released yesterday, look any better.

JavaFX is a new platform for development, based on Java. It combines a new set of media APIs and graphics rendering engine with a new scripting language (JavaFX Script), and wraps this in a set of integrated development tools and workflows. It still runs on the Java Runtime and can leverage that platform, which is, on paper, a good thing. That means you aren’t closed off from the powers of the Java platform, or even from the existing work done by Java ME.

All of this is great on paper. But Sun has a unique problem. JavaFX isn’t “Too Little, Too Late.” It’s “Too Little, Too Early.” It’s about playing catchup to Flash instead of extending on things Java can do that Flash can’t. And it simply isn’t ready yet. No one in their right mind would call this a finished 1.0 release. It’s an early beta, and the absurdly hyped-up talk from Sun and the Java community could turn the whole thing into a huge disaster.

Worst of all, it does exactly what everyone feared: it makes it even more unclear what Sun’s development plans are for the more-capable conventional, if aging and incomplete, Java APIs. And the whole point of JavaFX, distributing across devices? Tough luck: “1.0” works only on the latest Java 6 for desktop PCs and 64-bit Macs.

The slogan for JavaFX is “Do More.” Yep, that sums it up. For anyone to pay attention, JavaFX needs to Do More.

The short version:


  • Good 2D rendering
  • Timelines, animation
  • Works with NetBeans, integrated tool for working with artists
  • Plays media
  • Built on Java

Fine, if not earthshaking. And I will say, go try out the examples: there is promise here, especially if you call is a “Developer Preview” or some such thing. But then we look at the …


  • 3D not available yet; no roadmap
  • Media APIs limited to playback
  • Beta bugs and documentation holes in a “1.0” release
  • Murky open source plans
  • Still waiting on Linux and mobile deployment (mobile promised for spring 2009, but with some details missing)

So in other words, what they’ve done is to ship something that does what everything else already does (i.e., render 2D on desktops), only slightly buggy and poorly documented and actually less-compatible than proprietary alternatives. But you’re supposed to keep the faith, because it’s open source (well, except for the parts that aren’t), and because someday they’re going to ship other stuff.  Except there’s no detailed public roadmap for that stuff. And what they’re doing with the stuff you can already do in Java, like existing media and 3D frameworks? No word on that, either. (I think it’s telling that none of the JavaFX examples build on Java integration, even though that should be one of the JavaFX selling points.)

That’s not to say that JavaFX shows no promise at all. Maybe it’s too early – but then, Sun needs to adjust expectations. It’s a platform worth criticizing, and that means something. But I think it’s important to be really clear about that criticism now, because something is out of whack with the priorities here, and the larger Java platform could suffer as a result.

If this isn’t a rallying cry for the open source Java community to step up to the plate and do their own thing regardless of Sun, I don’t know what is. Sun seems asleep at the wheel when it comes to the real potential of Java, instead recreating a half-baked alternative. That could change as JavaFX matures, but it would mean not only more effort from Sun, but a more complete, community-driven, truly rich-media perspective.

All of these shots were taken from the JavaFX website – you can tell that they had Processing in mind, even if they failed to learn from what Processing actually does.

Do Less

Let me clarify. Here’s what JavaFX does, right now:

  • 2D rendering: This part actually looks quite good. Rendering is smooth, performance is good, and it’s possible to do 3D perspective transforms. The problem is, that’s all true of Flash and even Silverlight; until Sun can make a case that JavaFX is an ideal mobile platform and actually ready to deploy, this is a non-starter.
  • Timeline and animation: This is also a major plus – timelines (based on frames), motion paths, keyframe animation, and the like are now all easy to code. Note, I say easy to code. Artists accustomed to Flash won’t care because they may prefer the UI Adobe has built, something Sun (rightfully) didn’t take on. Coders might care, but it’s possible to code this in Flash, too – and it’s possible with a little elbow grease to write this stuff by hand in tools like Processing or traditional Java. JavaFX will have to (ahem) “do more” here, too.
  • Integrates with NetBeans, provides asset export from other tools: Here, JavaFX is able to at least catch up to Flex, minus the hundreds of dollars in cost.
  • Media playback: Sun has also included, for the first time, decent playback capabilities and media decoders for video and audio. They had to license proprietary algorithms for doing so because of patent confusion around open source options, but it’s something. The bad news: it’s still playing Flash catch-up on media,
  • Built on Java: Ironically, the best thing about JavaFX is not what’s new, but what’s old – the existing Java APIs, and the power of the VM and language – the stuff everyone (Sun included these days) likes to kick around.

The problem is, it needs to do more:

  • 3D RIAs are MIA, again: The whole point of Java to many of us is its ability to render 3D graphics, inside and out of the browser. It’s part of the cult-like appeal of Processing, part of why Java (via Processing) was so heavily featured earlier this year at New York’s Museum of Modern Art. Yet in JavaFX, minus a few simplistic 2.5D transforms the likes of which you already get in Flash, 3D is completely missing. If they called this a beta or an alpha, maybe that would be forgivable, but they’re saying it’s “possibly the most important technology this decade from Sun.” Sun could have spent this time and effort cleaning up one of their two existing 3D APIs in Java, JOGL and Java3D, or contributing to the lwjgl effort. Instead, they ignored 3D entirely and decided to do their best impression of Adobe, which didn’t work out so well. Sun can’t expect the competition to ignore this area, eit
    her: Microsoft, for one, is aggressively pursui
    ng 3D capabilities in its rich clients, and companies like Apple are pushing proprietary, platform-specific options like the OpenGL ES capabilities wrapped into the iPhone APIs. Sun lost valuable time and could wind up ceding this market if they don’t get their act together.
  • No real media APIs: Sure, JavaFX can play (some) video and audio files, thanks to technology Sun licensed from elsewhere. But it’s impossible to access byte data from either. You can’t do live synthesis and effects. You can’t process video signal. You can’t use the new media APIs to provide a front-end to other Java apps that process the image data. You can’t write custom filters. The real irony of all of this is that a lot of this is now possible even with Flash.
  • It’s a beta, at best: Documentation is missing. Links on the JavaFX site don’t work. The much-hyped ability to drag applets out of a window seems not to always function. APIs are missing. APIs are unpredictable. I know people are critical that Sun isn’t moving fast enough, and that products are too often “perpetually in beta.” But you know what? Call the thing what it is. The tech market doesn’t move as fast as people say; it rewards those who ship things when they’re done. This is 1.0 beta, at best, and even that’s generous.
  • It’s only sorta kinda open source. This one’s a bit murky. Java is open-sourced. JavaFX Script is covered under the GPL. But Sun is mum about all the new APIs. Media encoders are proprietary. Source is missing. It’s unclear how OpenJFX, JavaFX, JDK, and OpenJDK all relate going forward. This is at the very least another huge documentation whole that Sun could fill.
  • Linux, mobile deployment aren’t here yet. Correction: The requirement of Java 6 prior to 1.0 SDK’s release has been corrected with 1.0; JavaFX now runs anywhere Java 5 does. Java’s runtime still ships separately from JavaFX apps, but I’ll concede that point as Java 5 penetration is reasonably good. Unfortunately, Linux got left out entirely (so long, netbooks). And most importantly, mobile is missing. It might be worth all these other sacrifices if JavaFX did now what it promised to do in the first place: make mobile/desktop development seamless.he mobile version is promised for spring 2009, but some other details on the mobile runtime aren’t yet available. Again, why not say, this is a big task and we’re only getting started rather than “we’ve reinvented sliced bread”?

Sun is such an easy punching bag that it’d be easy to compare this to Flash and call it a day. But that actually would be missing the point – even as Sun tries to be Java Creative Suite or whatever you’re supposed to make of JavaFX.

Flash’s major limitation is that it’s largely tied to the desktop. (Flex, AIR, whatever – them, too.) To really work on mobile, it’d need a platform and standards-support that made it hardware-agnostic – all the things Java is, minus a significant amount of polish and consistency and work. Flash is also, despite some open-source bits here and there, largely proprietary. There’s nothing inherently wrong with that for many jobs, but what it means for the artist and bleeding-edge tech communities is, it’s not as hackable. Of course, so far JavaFX isn’t doing much better – and, ironically, mostly what JavaFX does is to make the old Java way of doing things look, if hard work, a lot more powerful.

But most of all, what JavaFX has done is to replicate all the things that are wrong with Flash for intensive development. Let’s call them hyper-rich applications.

JavaFX versus Processing

Building such a platform may be a lot of work. But if you want to look at an example, look no further than Processing is a fruitful comparison. These aren’t necessarily fair metrics by which to measure JavaFX, because the aim is different. But that’s the point: here’s a powerful set of uses that Sun seems incapable of grasping, one that may ultimately have a greater influence on the direction of digital development:

  • 1.0 Releases: Processing, like JavaFX, hit 1.0 in the past few weeks. Unlike JavaFX, Processing had a massive, multi-year development effort before it received that monker. And in comparison to the JavaFX development effort, which mostly took place behind closed doors at Sun, Processing was built by a genuine community effort who shaped what came out.
  • Simplified syntax: As elegant and powerful as JavaFX Script is, it’s actually easier to mix Java syntax and simplified, artist-friendly syntax in Processing than in JavaFX. It’s also easier to teach Processing’s syntax to non-coders, which was supposed to be the point of JavaFX Script.
  • Media-rich: Here, Processing suffers a whole lot because of how poor Sun has been as a caretaking of their own platform. Video and audio are, frankly, a disaster in Processing, thanks to the fact that Sun has let their media APIs mold and degrade. But Processing is a model for how you’d use this media, with the ability to process pixels directly instead of hiding them behind a dumbed-down, playback only metaphor. That makes, ahem, “processing” images, video, and sound much easier, which enables applications like computer vision, gestures, expressive display of images and videos, and much more. Flash, while more limited in comparison, also allows a lot of these things which JavaFX does not. And Processing is now evolving faster than JavaFX because of efforts to build real, open source APIs for media.
  • Community, community, community: From its goals to its documentation and code examples to the art made with it, Processing’s creators have been responsive to a community of artists, teachers, and innovators. It’s not enough to be open source. Open source, in the end, is meaningless without a community effort driving development and deployment.

Of course, another problem Processing inherits from Java is that deployment on mobiles is a separate process, and compatibility is inconsistent – because mobile Processing is based on Java ME. But that doesn’t score any points for JavaFX, because mobile is still missing. (In fact, it makes me wonder: why not do mobile deployment first?)

And this means, whatever JavaFX may be in the future, if it can’t compete with Processing or even traditional Java development, even on desktop media-rich development, it’s got a long, long, long way to go.

All Hope Isn’t Lost Yet

So, okay, that was a long rant – it’s a complex platform. But here’s why I haven’t lost hope. There are various scenarios that could improve the situation.

Sun could provide better documentation and roadmaps. 3D and mobile are planned – fantastic. Sun needs to document better what’s there now, and what’s coming, and how, and when. If “2.0” is going to fix all of this, Sun needs to not just promise, but deliver consistent, reliable information and more frequent developer builds.

Sun could focus on 3D. 3D, even limited to the desktop, has so far eluded competing tools. Sun could make this the leading sales point of JavaFX and focus on doing it well. Even if they started on desktops, they have some time before mobile 3D capabilities become more usable on more devices.

Sun could focus on mobile. Alternatively (and perhaps more practically), Sun could focus on getting mobile out the door, which should have been the emphasis earlier on. I’d be willing to suspend a lot of my other complaints here if you could build something simple but be assured you could deploy it across mobil
e devices. Again, don’t make
us wait: give us frequent information and builds, and you might be able to win back some trust.

Open source could step up. I don’t work for Sun, so at a certain point I have to focus on what I can do. Open source community, this is your time. Java remains the most complete platform, aside from C/C++, for rich media development. It has a powerful, fast language and VM. It’s capable of running all kinds of elegant languages if the traditional Java language doesn’t appeal. Cross-platform frameworks for C/C++ are great for some jobs and have a lot of future potential. But there’s also likely to be a place for something like Java. From artists to researchers, we still need the thing – and it isn’t a lost cause yet.

Open source lovers – including the Processing community – could focus on priorities that are unlikely to be of interest to Sun:

  • Advanced media processing and codec support
  • Applications like computer vision
  • Sample-accurate timing frameworks for audio and music
  • Rich 3D support
  • Support for unique hardware inputs like multi-touch, haptics
  • Student- and artist-friendly APIs

I already put more faith in communities for tools like Processing or even the 3D gaming engine jMonkeyEngine when it comes to these kinds of capabilities. And as they patch holes for these projects, they could contribute libraries that can be used by everyone.

No matter how limited the market for these things is, I think you can already see it means going in a more interesting direction. I’m sure Sun doesn’t think that things like MIDI and sound/synthesis support matter to a wide audience. Truth is, they’re right. And I don’t expect them to understand that empowering these features could actually create the kind of community they most desperately want – one that’s future-thinking, creative, artistic, and, darnit, cool. I don’t think that’s their job – it’s ours. Sun’s job on the OpenJDK and beyond should be to pay attention to what we’re doing and make sure their stewardship of the open-source side of Java gives us the freedom to keep working.

So, I’m not wasting any more time on this stuff. I’m getting back to “traditional,” non-futuristic Java development.

  • Kris

    Great article, and even longer than the processing one. Would be great to find out which ends up being a better platform for audio / visual production.

  • Well, that's an easy one, at least for the foreseeable future. JavaFX has simple audio + video playback only. That makes it pretty much a nonstarter for a/v production applications. Processing has a very workable sound playback library. Video is problematic with the included library based on QuickTime for Java, it's true. But because of the architecture of Processing, it's not a big deal to substitute a different library. So right now you can use something like gsvideo. It's not easy to deploy what you create, but it's not impossible, either — and if you're talking about "production" you may be happy getting it going on a single machine (which is just fine for pros, too, if their goal is installation).

    So my sense is Processing – and the existing Java platform on which it's based – both have a big headstart on JavaFX, a more open approach architecturally, and there's no sign right now that that's changing any time soon.

    None of these translates easily to mobiles at the moment, but that's another story.

  • Sakuraba

    I really had hopes this would turn out a different way. Tried out the samples on my OSX 10.5 MacBook Pro even with Java 6 installed (a one-click-installer should start if the prerequisites of a javafx script are not available!!!). None of the samples ran! All I could see was a spinning-loading icon goind on forever. When I tried the mp3 player, my browser crashed and Iost all of my open tabs of valuable information, that cant be recovered (cant open from last session…).

    Sigh… how is JavaFX now different from traditional applets for the end-user? How many dollars have been spent to make this work?

    If this is truely the best that Sun can do, then 3 $ per share is still too much money.

  • Steven H.

    Some of the facts here are incorrect.

    JavaFX runs perfectly fine on 32bit Java 1.5 on the mac. I refer you to http://www.javafx.com/faq/#1 – Question 1.9

    There are some features are only available on Java 1.6 update 10 – specifically the dragable applets, and these limitations have been well telegraphed, along with the information that Linux and Solaris support is being extensively worked on. Apple is also in the loop, but – as usual – not to much would be said about it.

    As far as the docs being 'missing', well, I'm in the process of writing an application using only the samples and sample doc, and compared to a great deal of open source projects, the documentation is pretty damn good.

    There have been issues with the JavaFX site – this may account for some of the issues people have loading the samples. But its been reliable most of the time.

  • Steven, mea culpa – I was patently wrong on Java 1.6 vs. 1.5, as I had been confused by the runtime requirements of the pre-1.0 version. Java 6 on Mac certainly requires Leopard + a 64-bit machine, but that's correct, Java 1.5 on both Mac and Windows (which lacks the 64-bit requirement), and Java 1.6 update 10 (32/64) all work.

    I'm still concerned about mobile deployment, because it isn't here yet.

    I may be getting overly grumpy because of the cumulative effect of all these problems, and yes, plenty of open source projects are poorly documented. (Others are documented very well.) I am still seeing various issues with the documentation and JavaFX site that just tell me it wasn't done yet. I'm confused, as well, why common / desktop API links aren't working for me in the API documentation, unless there aren't yet any API calls that are desktop-only.

    I've yet to see tear-off functionality work right on Java 6 update 10 Windows.

    Once we see mobile deployment and perhaps a smoothed-out release, then I could see this becoming very useful for developing across mobiles and desktops. But what I had heard from the JavaFX team was that they were interested in attracting artists and creative work. That was never their core audience, so, fine, but certainly you can see a little Processing envy or a desire for something different even on the JavaFX pages. And I just don't see it happening any time soon. I'm perfectly happy to wait for a deeper, more sophisticated version — as long as that takes. But the hype now to me is way out of proportion.

  • @Sakuraba: To me, the most important difference relative to traditional applets is mobile compatibility. So there really is potential for something that's worth the development effort here. The problem is, in its current form, I think a whole lot of people (in web dev circles, too) are going to have the reaction you did. That's going to make it hard for Sun to trumpet things that do deserve hype when they're fully baked.

    That's also why I feel strongly that if a product gets severely over-hyped there's no benefit to the product if the rest of us play along. Beat the thing up now, and if it gets fixed or matures, give praise where and *when* it's due.

  • Zeh

    In the meantime, Flash 10 is being ported to a handful of mobile devices (G1, Symbian-based Nokia phones, iPhone) and is now able to run re-compiled native C/C++ code in SWFs.

    Flash has always been the ugly midget duck but Sun has a lot of catchup (or at least reorganizing) to do.

  • Well, right, and the advantage of being Sun/Java – one I think that's highly underrated – is the ability to do all this stuff Flash can't. So to me, I think the draw of JavaFX could be dependent on what its 3D support looks like. That's not to say that everything needs 3D — I certainly don't believe that — but that when you want to do 3D, Java could be your choice. We just won't know until they deliver it.

  • Josh Marinacci

    Hi. This is Josh Marinacci from the JavaFX team at Sun. Many of your points are spot on. Please remember that this is a first release. We have plenty planned for future releases. You can use the beta of JavaFX for mobile in the mobile emulator today on Windows. Support for deploying to real mobile devices is coming in the spring, with a beta of JavaFX 2.0 in early summer. This is just the beginning.

    If you have any other questions please feel free to email me: joshua.marinacci@sun.com.

    We genuinely value feedback, especially from people who have a foot both in the developer and design communities.

  • Martin S

    Very good article, dives into the concerns many of us have. As a Linux user I have to settle with just reading about it rather than actually trying it out. That's a little disappointing from a company that owes its success to write-once, run-anywhere.

  • Peter,

    Multithreading and the myriad of libraries are more relevant than 3D for most enterprise usage.
    Sun should also focus on that.

    Try to create a data intensive ( pulling ) app in Flex w/o backgrond processes or worker threads, etc. and not breaking the smooth user experience.


  • @Josh: Thanks for that. Well, you know, that's the idea – I'm not pulling any punches, just being honest about what I think, and I do look forward to watching it evolve.

    Actually, reading the comments, I realize in addition to ranting, I should also be asking some questions. I'm curious about what will be required as far as mobile devices. What happens with things like Android, for instance, which at this point has only allowed development via Google's own APIs (albeit in the Java language). That's a Google question, but on the other hand, if Google was to allow the use of JavaFX on the Android platform, that'd be fantastic news for both. And one important question:

    @Aldo: good point. Needless to say, this isn't an enterprise blog, but multithreading is important to all of us. I'm not actually sure how you create a thread from inside JavaFX. You can, however, mix JavaFX and Java, so your Java code is threaded normally and you can absolutely make use of Java for everything else — I'm sure the idea is to use Java for the data-instensive stuff. And there, there's no question that JavaFX has an edge over Flex — it just happens to be with the Java stuff with which you're already familiar.

  • Kevin Jordan

    I'd like to see better integration with Swing, or maybe have JavaFX have its own UI widgets. It has no internal frames by itself. Sure you can wrap a JInternalFrame and use that in there, but you can't put anything you draw with JavaFX inside there. Which makes me wonder, is there anything JavaFX can do that Java couldn't do previously? Is all JavaFX does is redo what you can do in Java in a simpler JavaScript form?

  • @Kevin: Well, generally speaking, no, there isn't anything JavaFX can do that Java can't. But that much I get — the idea was to do these things better. And it's not JavaScript; JavaFX Script is declarative by design and it's possible to mix JavaFX with Java (the language) and Java (the platform / libraries built on Java), neither of which is possible with JavaScript or ActionScript / Flash / Flex. (When people talk about mixing Java and Flex/Flash, it's usually communicating with separate code written in Java, and most often Java on the server and Flex/Flash on the client — not quite the same.)

    My issue is, the scope isn't quite there to make the whole package useful. So we really do need to see the mobile support picture, and I think to fully differentiate Java, we need to see what that 3D support looks like.

    Back to your original question, though, yes, some of those UI features aren't there yet, either.

  • Josh Marinacci

    @peter JavaFX itself is a single threaded language. Everything happens on the GUI thread. For things which need threading (network IO access, animation, etc.) we provide an API which does the threading for you (like background loading of images) or you can drop down to Java code, which has the robust multi-threaded capabilities that we all know and love. I have a new version coming out of my PrimeFactors sample that will use Java for the computation instead of JavaFX Script (but leave the UI in JavaFX). This way it can use threads and be 2x as fast on my laptop w/ 2 cores. Using FX for the UI and Java for the lower level stuff is definitely a good combo.

    Also: our VP of Marketing has officially said that we are going to port JavaFX to Android. We showed a demo of it at JavaOne. I expect more details at the mobile conf in feb.

    @Kevin we are working on more Swing mixing. You can drop any Swing component or panel in your FX scene graph today, though. There's a sample on javafx.com that shows how. We are also planning a set of 100% FX components. JavaFX adds animation, video, effects, and more. It lets you do things that were hard or impossible in straight Java, but it's still built on top of Java and the JVM.

  • Pingback: Schreibtischnotizen » Blog Archive » Java FX 1.0 API - was geht, was geht nicht()

  • Pingback: rascunho » Blog Archive » links for 2008-12-08()

  • Pingback: JavaFX 1.0 Released | Enetlive.net- Rich Internet Applications Blog()

  • Joseph


    A small precision : it runs fine on Linux (at least on my ubuntu 8.04), it's "only" the dev environment which isn't (yet) available.

    Hope it helps !


  • Vaibhav

    This is indeed a good article. I hope, javafx development is going faster and soon you will see those things which is counted as the limitation today.

  • Scott Hommel


    There is actually plenty of documentation with this release.

    Overview: http://www.javafx.com/learn/

    Tutorials (core, GUI, and media): http://www.javafx.com/docs/tutorials/

    API Docs: http://java.sun.com/javafx/1/docs/api/

    Language Reference: http://openjfx.java.sun.com/current-build/doc/ref

    FAQ http://www.javafx.com/faq/

  • amar shukla

    JavaFX 1.0 is just a bit of crap nothing else .

    NO necessary libraries , tools are there . Documentation itself is incomplete . It seems as SUN just wanted to be in the Race of RIA and other thing is becoz ADOBE is going to launch FLEX 4 in March or so . So SUN just wanted to show that we are also there .

    Really unexpected release from SUN.

  • javafxnut

    im learning processing with the eventuality of learning java. I saw javafx and have started 'porting' my uni assignments for practice. I think java sorely needs to be developed coz it just looks old 'n grey in xp or vista. linux's gtk has the same issue. Try jfxbuilder – its unreal