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:
- 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 …
Bad:
- 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.
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.