JavaFX: Client-Side Java for Desktop and Mobile

Posted by Geoffrey Wiseman on Oct 03, 2007 07:30 AM

Community

Java

Topics

Rich Internet Apps,

Rich Client / Desktop

Tags

JavaFX Script,

JavaFX Mobile

Since JavaFX was first announced at JavaOne in May, there has been a flurry of activity focused on improving the client-side user experience of Java.

Joshua Marinacci, from the Swing Toolkit Team at sun, recently called to attention the collection of technologies that can be considered part of the JavaFX effort in JavaFX != JavaFX Script:

The marketing definition of JavaFX is a set of products and technologies for creating rich user experiences.

So what does that mean in non-marketing speak? It means we are producing a bunch of new stuff that focuses on the client side; on the user. This means both new technologies for making great looking new applications, and improvements to existing technologies to make them better. JavaFX is radical improvements to client Java so that we can build the apps of the future. I really prefer the term User Experience here rather than User Interface because it's more than just the GUI components and eyecandy. It's also the experience of installing Java, running Java apps, and getting updates. It's about speed and reliability. It's not just about the creation experience, but also the runtime experience. All of these are important parts of your user's 'experience', even more than the UI widgets.

He itemizes the technologies under the JavaFX Umbrella:

• JavaFX Script
• Designer and Developer Tools
• JavaFX Mobile
• The Consumer JRE (including: deployment toolkit, new installer, java kernel, quick starter, media, nimbus)
  

InfoQ interviewed Joshua Marinacci on these and other topics.

JavaFX Script

JavaFX Script is making strides as a new way to build client-side Java applications. Recent tutorials for JavaFX have introduced the basic concepts, the canvas for 2D vector drawing, and client-server communication with RMI and JAX-WS and reproduced a page from a graphically rich website.

The tools have also continued to make progress, from the JavaFXPad demo and JFXBuilder to the JavaFX Script Plugin for NetBeans.

Although JavaFX script is not ready for production use, and currently a little slow, it is very much a work in progress. It is, however, built on top of a very mature set of Java client-side technologies:

JavaFX Script (which is just part of JavaFX) is still very alpha and not yet ready for primetime. The language is still being developed so I don't want anyone trying to ship apps with it yet. However, FX script is just a new way of accessing the rich features of the very mature JavaSE stack. You get tons of high quality open source libraries on a fast and stable runtime. You can develop in many different languages. And best of all you can easily work with powerful server-side Java applications.

Designer and Developer Tools

In addition to the JavaFX script tools already described, there will be other tools targeting the designer and developer under the JavaFX umbrella:

For designers we are making a brand new toolset. It will certainly share code with our other tools but it will not just be some modules for NetBeans. This is a full set of tools targeted specifically at designers and content creators. More like Flash and less like an IDE. We will probably also add some FX support to the NetBeans GUI builder (formerly Matisse) but that is separate from the pure designer tool.
I'm really very excited to be on the team building this new designer product. We've got some great people working on it and a slew of awesome ideas. I think a lot of people will be pleasantly surprised.

For developers we are working on plugins for NetBeans (which you can see in alpha form today) as well as a full fledged compiler done completely as an open source project on Java.net. The compiler is designed to work apart from an IDE, though we will obviously have great integration with NetBeans.

JavaFX Mobile

JavaFX Mobile builds on the stack that Sun acquired with SavaJe to provide a complete stack from OS to frameworks and applications for mobile devices:

One of the goals of JavaFX (not just JavaFX Mobile) is to end the fragmented platforms.
We've often said that fragmenting Java is a bad thing (duh!) and that's why we very, very carefully open sourced Java the way we did. Keeping Java from fragmenting is probably the most important thing in the Java ecosystem. If this true (and I most certainly believe it is) then it makes no sense to leave the mobile side fragmented while desktop & server Java are unified. So that's what we are addressing with JavaFX Mobile in the following ways:

1. JavaFX Mobile is a complete mobile stack & implementation. It's not just a bunch of specs, but an actual (single) implementation. Essentially it's an entire OS + apps + apis written entirely in Java. Only the kernel and some device drivers are written in C.
2. We can update the system in the field. No longer will the mobile market be fragmented by older implementations that are missing bug fixes or current features. Every device can be the same version of the platform.
3. JavaFX Mobile is designed for higher end phones, this means it approaches the capabilities of JavaSE.

[The third point] is really the most important here. Our long term goal is convergence between JavaSE and JavaME. No longer will you need to know multiple APIs. There will be only one Java.

Although Josh couldn't offer insight into which carriers may be offering JavaFX Mobile devices, or comment on the Google phone rumors ("I read the rumor sites as eagerly as everyone else"), he offers some insight on the impact of the iPhone:

I will say one thing, though. People often wonder how JavaFX Mobile will compete with Apple's iPhone. The iPhone is actually wonderful for JavaFX Mobile. Suppose you are a handset manufacturer or a carrier who didn't get an exclusive deal with Apple. If you want to make an iPhone-like device Apple certainly isn't going to help you out by selling an operating system and apps for your devices. But Sun will... The mobile world is going to get a lot more exciting over the next few years.

Consumer JRE

The Consumer JRE is itself another cluster of technologies that has recently seen its first preview release, including the Nimbus look and feel.

The Consumer JRE should help consumers who just want to use applications that happen to be written in Java get started in a much more streamlined and less time-consuming process than is currently possible. And with a quickstart mechanism and hardware acceleration, Java will be more responsive than ever before.

A big thing people don't realize is part of JavaFX is the Java SE 6 update N (formerly Project Hamburg, formerly the Consumer JRE). This is a new release of JavaSE 6 with tremendous improvements to the installation and deployment experience. Installation and deployment may sound boring, but it's the first thing users see when they start or install a Java app so it really matters a lot. The changes coming soon in JavaSE are really the underpinnings of the many cooler things visible at the top of the JavaFX stack. And they are useful even if you don't use anything else in JavaFX. Look for the first update release of Java SE 6 in the spring.

Finally, the Nimbus look and feel and Media integration should make the Java experience a rich and pleasing one:

My understanding is that the biggest challenges of dealing with media (and most specifically video) are legal and not technical, so it's definitely not a case of Java not being fast or powerful enough. The first version of new media support should support playback and frame grabbing, which is enough to do most of the cool things people want on the web. We aren't creating a full editing API like Quicktime, but you'll be able to do the basics very easily.

So ...

With all these ambitious plans in the works, do Sun and Java have what it takes to make a significant dent in the media-rich, glossy desktop applications of the future? Or is Java on the client a dream whose time has come and gone? Josh speaks to the credibility of these efforts

Sun has tackled the enterprise client side space and been very successful. You would be surprised how many large companies use Swing based billing and sales systems. Sun has never really gone after the consumer client side before (at least not in 10 years). Now we are, and that's why this is different.

I ask people not to believe our words but instead look at what we are actually doing. Try out development builds of JDK 7. Look at the new deployment features coming soon in the beta of the new Java SE 6 update. Play with JavaFX Script. Use the NetBeans GUI builder. We are making real changes the client side. I understand that some people feel Sun is a server company and doesn't have the credibility on the client side, so just look at what we are actually doing and shipping. I agree it's a big change, but the world is changing. The web isn't what it was 5 years ago. The mobile world is being shaken up. Everything is changing, including Sun.

For more information, join the OpenJFX project, go see Josh speak about JavaFX and stay tuned to InfoQ's Java Community.

1. Back to top

   Are you a believer?

   Oct 3, 2007 10:26 AM by Geoffrey Wiseman

   On a personal basis, I'm really happy to see Sun/Java tackling the consumer client-side space; but I wish it had happened a long time ago, and I worry that it might be too late, what with AIR and other rich media technologies creeping in, and the general public's lack of faith in client-side Java might be difficult to overcome. Still, interesting, and I'll keep my fingers crossed.

   Reply

2. Back to top

   JavaFX must have video to succeed

   Oct 4, 2007 4:50 PM by Andy DePue

   This may seem trivial, but the one thing that has made Flash so successful is its video support. If JavaFX is ever going to compete or succeed in its target market, then it must have built in video support that is at least as easy to use as Flash's. And no, being able to invoke platform codecs doesn't count, because what we really care about is getting video to the end user, no matter what OS they are running. If we need to re-encode the video to a JavaFX specific codec, then so be it, as long as it plays everywhere with decent quality. Sun is going about this completely backwards, starting off with NO built in video support, and then moving to platform specific support, and finally, maybe, implementing a built in codec that can play anywhere. Sun better rethink this strategy, or JavaFX will die before they even develop a built in codec.

   Reply

• Older >