 | Level: Introductory Elliotte Harold (elharo@metalab.unc.edu), Adjunct Professor, Polytechnic University
05 Jun 2007 Code was written, language extensions were debated, robots
danced, and much beer was quaffed -- by all accounts this year's JavaOne
developer conference was a success. Looking back, Elliotte Rusty
Harold finds that JavaFX Script is the biggest news to come out of the
conference, along with other client-side initiatives. Find out what Sun's
reinvestment in the client means for Java™-based rich Internet application development in the year ahead.
Last month marked the twelfth iteration of Sun Microsystems' annual
JavaOne extravaganza. What started as a small spinoff of Software Development
West back in 1996 has become possibly the single largest developer conference
still standing. Somewhere between 10,000 and 15,000 people spent a week
listening to their peers and colleagues talk about subjects as diverse as
Scala, REST, Java Enterprise Edition (JEE), rich Internet applications (RIA),
robotics, Swing, Blu-ray, and more.
In hindsight, the message that emerged from the show is that the server
side has peaked, at least on the Java platform. JEE and related technologies
like Hibernate, Spring, and servlets are old news. Sure, developers are still
using them, but they're almost legacy code at this point. Little if anything
new was said about Java-based server-side technologies at the conference, and
they were almost completely absent from the keynotes. Instead, Java developers
who focus on the server side are looking to Ruby, Rails, and REST for
salvation. (It could be said that this makes them former Java developers.)
Undeniably, in the Java space, the action has shifted back to the client.
Speakers, mostly from Sun, showcased many new developments in Java 2D, Swing, AJAX, and GUI builders, and all were eagerly consumed by conference attendees. I'll
discuss some of the highlights in this report back from JavaOne 2007.
In the spotlight: JavaFX Script
|
No real surprises
To be honest, JavaFX Script wasn't all that unexpected: I among others had predicted
something almost exactly like it would emerge at the conference. If you knew where to look, you could even find it in the JavaOne catalog, buried under its codename, F3. Rich Green just doesn't match Steve Jobs for surprises and "one more thing." |
|
The single biggest announcement of JavaOne this year was Chris Oliver's
JavaFX Script, a declarative language for writing Flash-like
rich Internet applications. JavaFX Script takes advantage of Java 2D to create
non-standard widgets like burning flames, rotating color wheels, and buttons
fashioned after the head of your favorite pop star.
Listing 1 shows a simple application written in JavaFX Script that rotates
a red radial line around a blue circle and Figure 1 shows the application
running:
Listing 1. A simple
animation written in JavaFX Script
import javafx.ui.*;
import javafx.ui.canvas.*;
Frame {
title: "JavaFX Whirl"
width: 200
height: 225
var rot = [0..360] dur 36000 linear
content: Canvas {
content: [Circle {
cx: 100
cy: 100
radius: 100
fill: blue
}, Line {
transform: bind [rotate(rot, 100, 100)]
x1: 100
y1: 100
x2: 100
y2: 0
stroke: red
strokeWidth: 3
}]
}
visible: true
} |
Figure 1. A JavaFX Script application
Experienced Web developers will notice that the application in Figure 1 is reminiscent of Scalable Vector Graphics (SVG) and Apple's canvas element. The key difference is that SVG and canvas rely on procedural JavaScript to define behavior,
whereas in JavaFX Script, the behavior is declarative as well.
Some clear challenges
JavaFX Script rendering is all done with Swing and Java 2D, which raises a
couple of issues. The first is whether the Java platform is fast enough to
handle rich Internet applications. Java-based GUI performance is slow in
general, and on Java 2D apps in particular. Although the Java platform is a
lot faster than it used to be for mathematical and server-type operations, the
client is still a sticking point. Sun hopes to remedy this in the near future
by turning on DirectX and OpenGL accelerated graphics by default. Furthermore,
it plans to use accelerated graphics for most Java 2D operations rather than
just the basic operations that are accelerated now.
These changes should bring acceptable performance
on modern hardware with adequate graphics cards.
In addition, JavaFX Script is currently interpreted by the Java virtual
machine (VM) at runtime, though that's likely to change. Sun has recently hired Per Bothner to work on a byte-code compiler, which should dramatically improve the performance of JavaFX Script applications once it's completed.
The second issue is whether JavaFX Script does anything that can't be
done today with Swing. The answer is no. JavaFX Script is really just another
language that can be compiled into Java byte code. However, JavaFX Script is
more declarative and simpler to write than classic Java code, at least for the
sort of rich Internet application development it is intended for.
The real question on everyone's mind is, of course, whether JavaFX Script will displace or at least challenge Flash. My guess is
no. The Java language has always been able to do anything Flash could do. It just
takes longer to write. An applet that takes a talented Flash pro three hours to crank out would take three weeks to copy in the Java language. JavaFX Script closes the gap, so now it only takes three days for a Java programmer to do what a Flash pro can do in three hours. That's better, but it's still not nearly enough.
The real issue is tools: Sun doesn't have any. JavaFX Script is authored by
hand in a text editor like jEdit, vi, or NetBeans. There's no equivalent to
Adobe's Flash development environment. The art school graduates reinventing
the Web around Flash, for better or worse, will not find JavaFX Script any
more approachable than Java code. The ones who will like JavaFX Script are already writing straight Java code today, and there just
aren't that many people who are skilled as both programmers and rich client
designers. Until Sun gets its tool story together and comes out with a real
competitor for Flash, JavaFX Script is an also ran.
Deployment solutions
Besides authoring, deployment has been a classic problem for rich Internet
applications written in Java code. Major consumer applications such as LimeWire
stick with outdated Java Runtime Environments (JREs) because they don't want
to incur the hassle of bundling larger, more recent VMs. Various sessions
at JavaOne this year discussed ongoing efforts to address deployment issues.
In particular, Ethan Nicholas told us that "Easy Deployment Is Finally Here," though he may have jumped the gun a little bit. Most of the proposed solutions he described (discussed below) should see the light of day in Java 7 early next year. Some of the more under-the-hood changes may even be released in an update to Java 6.
Redesign the Installer
Step 1 is an installer your parents could use unassisted. The
current installers are ugly, complicated, and don't do what you expect half
the time. They're really only adequate for developers. The next JRE installer
will be cleaned up and aimed at end users.
Sun is also working on improving the ActiveX controls, plug-ins,
and JavaScript programs that enable a browser to detect whether a Java VM is installed
and, if so, in which version. A new Deployment Toolkit should make it easier to prompt the
user to install a Java VM if they don't have it or don't have the right version. The
Deployment Toolkit is for the Windows® operating system only for now, but it will work on Firefox as well as Internet Explorer®.
For the Mac, Sun is still relying on Apple to ship a Java VM with every
Mac sold. This works well enough until Sun starts saying silly things like
"It's time to move to Java 6" (a mantra repeated by various Sun employees
throughout the conference). Apple likely won't even have a Java 6 VM until this fall, and most Macs won't be upgraded for some years to come.
The JRE should be in much better shape on Linux®. Sun supports Linux
officially, and now that the JDK is under the GPL, client-focused distros like
Ubuntu can start bundling the JRE. (A lot of laptops were running Ubuntu at
the conference. It has clearly become the desktop distribution of choice.) By
this time next year, users shouldn't have to download or install the JRE onto
Linux at all. It should just be there.
Warm up cold starts
Step 2 is reducing VM startup time, especially for applets. The 10-second
pause the first time a browser encounters an applet would be considered a
denial of service attack if we actually cared about users. Sun could launch
the VM as soon as the browser starts up, but that would occupy a lot of
memory that wouldn't be needed most of the time. Instead, Sun is planning to
preload .class files into the disk cache. This doesn't occupy RAM or take up
CPU like starting the virtual machine would, but it does allow for much faster
startups when the VM is launched the first time. Look for this technology to
appear in a "Consumer JRE" late this year or early next year.
For standalone applications, it may be possible to go even further. Class
file verification and just-in-time compilation can be done before the
application runs, or perhaps just the first time the application runs. The
verified, compiled code can be stored. Subsequent runs can start right away
with the real compiled native code rather than stopping to do verification and
compilation first.
Shrink the JRE
Step 3 is to shrink the JRE and even allow custom VMs for custom apps.
Work is ongoing to produce a small (maybe 4MB) basic distribution
that is just smart enough to run "Hello World" and download whatever else it needs on the fly. Let's face it: who really needs org.omg.CORBA and javax.imageio anyway? Third-party developers will be able to create virtual machines that
bundle just the classes their application requires. For many applications, the custom VM could reduce the memory needed by
half or more.
From JARs to JAM
Finally, step 4 is to eliminate classpath hell. As explained by Stanley M.
Ho and Michal Cierniak, Java 7 will introduce a new JAR format called
Java Archive Module (JAM). A JAM file is a JAR file (which itself is just a ZIP
file with a different extension and some metadata), but it contains extra
metadata and allows JARs to be nested. That is, a JAM file can contain one or
more JAR archives. Thus it will be possible to bundle all the classes an
application needs into a single file. Furthermore, the additional metadata
will enable classes to declare dependencies not just on other JARs but on
specific versions of other JARs. If you know your application works with
Xerces-J 2.6.1 but encounters subtle bugs with 2.6.2, you can ask for 2.6.1
explicitly. Finally, there will be repositories for storing all the different
JARs. You can have separate global, bootstrap, application, local, and even
network repositories. (Sounds like an opportunity for conflict to me,
actually.) jre/lib/ext should be emptied.
None of these features is earth shattering individually, but taken together
they do add up. The end result will be a small but noticeable improvement in
the end user's Java client experience.
Simpler Swing development
Deployment improvements help the end user, but what about the poor, overworked client developer? Sun didn't have quite as much to offer here, but there were several notable developments.
The Swing Application Framework
Until now, Swing has only defined individual components, offering classes
for buttons, windows, menus, and so forth. It's up to the developer to glue
them all together to make an application, however, and that can be
tedious.
The Swing Application Framework, demoed by Joshua Marinacci and Hans
Muller, puts existing components like JFrame and
JMenu together into a complete (if minimal)
application that can be extended with custom code. Figure 2 shows an application built with the Swing Application Framework. The
most important thing to note is that you can create an application like this
in a wizard by filling out a couple of class names, choosing a directory, and
pressing a button. It saves a lot of work.
Figure
2. A simple application built using the Swing Application Framework
Currently, the Swing Application Framework only supports single-window
applications, but multiple-window applications will be added going forward.
When using the framework, you just plug your own code in at particular
points in the application's life cycle such as startup and shutdown. Of
course, you can attach actions to components, too. In addition, the framework
makes it a lot easier to create asynchronous and modal actions.
The danger of blocking the event dispatch thread in Swing is well known,
but more programmers still get it wrong than right. The Swing Application
Framework aims to make doing the right thing easier.
What about Matisse?
To customize Swing-based GUIs, Sun recommends the Matisse GUI Builder.
Matisse allows you to drag and drop components onto a window and set their
properties graphically. It's easier to use (especially for layout) than
arranging everything in raw source code. The downside of using Matisse is that
you'll find that your GUI code full of comments like this one:
* WARNING: Do NOT modify this code. The content of this method is
* always regenerated by the Form Editor. |
This is a major design flaw. Generated code should be kept in a separate
file and should not be mixed with application code. Furthermore, choosing
Matisse locks you into using NetBeans as your IDE. You can bring the code into other IDEs such as Eclipse, but if you bring it back into NetBeans, Matisse will be thoroughly confused. This may not be an issue for a single developer or a
closed shop, but it's a major problem for open source team projects where
different developers use different tools.
Overall, Matisse looks like a good first effort with some promise, but it's
not ready for prime time yet.
Filthy Rich Clients
Of course, if you've actually got more time than work (and if monkeys
learn to talk and begin quoting the lost sonnets of Shakespeare), you can build
GUIs all by yourself, with nothing more than raw code and a text editor.
Romain Guy and Chet Haase demonstrated Filthy Rich Clients and performed an
Extreme GUI Makeover, proving by example that Swing applications don't have to
look like grey boxes inside grey boxes. In essence, they did in straight Java code
(with a couple of tricks delegated to Java Native Access) what Chris Oliver
did in JavaFX Script. It was very impressive work, but way beyond my skills.
One thing that both the Filthy Rich Clients approach and JavaFX Script have
in common is that a huge amount of the design work is done in Photoshop. Most of what's actually displayed on the screen are custom Swing
components that render images painted in Photoshop. This is a very interesting technique
provided you have the skills to design GUI widgets in Photoshop. Thus
for Kai Krause and Romain Guy, this is really cool beans, but the rest of us may be condemned to
grey-box designs for some time to come or at least unless we can afford to
hire someone with the graphic design skills most of us programmers lack.
Free as in Java code
The next big news that wasn't news at JavaOne is that
Sun has finally drunk the open source Kool-aid. At the opening keynote on
Tuesday, Rich Green released the complete JDK under the GPL.
Well, not quite. It was revealed that because of ongoing licensing and legal
encumbrances, a few bits and pieces will only be available as binary plug-ins.
While most of the JDK is now indeed open source, about 4% isn't. In particular,
these six pieces are still encumbered:
- Graphics rasterizer
- Font rasterizer
- Color chooser
- Parts of the Sound API
- SNMP
- A small part of crypto
The first five items involve code from third parties. Sun declined to name
the third parties involved; whoever they are, they have refused to allow
their code to be released under the GPL. Patent issues may also be involved in
the font rasterizer. Sun is hoping that the community will contribute
unencumbered replacements for these pieces in the near future.
The crypto classes are a separate issue. Sun claims there are legal
restrictions on shipping an unobfuscated version. I am not a lawyer, but I
tend to doubt that. However, Sun's been in bed with the military industrial
complex since its founding, so it is unlikely to want to test the limits
here. While crypto is possibly the easiest of the five pieces to swap out and
replace -- much of the work has already been done in third-party projects like
Bouncy Castle -- Sun will probably not ever agree to ship its code. A
genuine fork will probably be necessary to cure this last hurdle.
Going forward, there will be a separate OpenJDK project and product, which
will be at least theoretically independent of Sun. Sun will base its official JDK on the OpenJDK product,
but there may be differences. An initial governing board has been formed
consisting of Simon Phipps, Dalibor Topic, Mark Reinhold, Doug Lea, and Fabian
Nardon. They're charged with writing a constitution and holding elections for
the next governing board. Sounds like a plan.
Many language proposals
Numerous sessions addressed language proposals such as closures,
reified generics, type inference, and more. These topics were even more
discussed in hallway conversations and at various bars after the conference.
I can't rule out the possibility that my internal filters were steering me
into the conversations I already agreed with, but I really got the impression
that there's a growing disconnect between the developers designing the next
version of the Java language and the developers using it. While Sun
speakers kept repeating the message that we should all be using Java 6, many
of the attendees had only switched to Java 1.4 for production in the last
year, and most were just starting to get comfortable with Java 5. Java 6
wasn't even on their radar.
Going forward, attendees were hugely enthusiastic about breaking
with the past and cleaning up the Java libraries, even at the expense of
backward compatibility. By contrast, Sun speakers continued to stress the need for backward compatibility at all costs.
As for new features in the language, most attendees were lukewarm at best,
even when discussing sexy topics like closures. To the extent that the Java
language wasn't meeting their needs, most attendees seemed to prefer learning a
a new language entirely, such as Scala, rather than adding more features to
the Java language. Fortunately for them, Neal Gafter predicted that there will be no new language features in Java 7. Closures and other such major changes will have to wait for Java 8.
Ruby and Scala were the big winners here. In this much, at least, Sun and
the rest of the Java world are in sync. Sun is beefing up support for
dynamically typed scripting languages in the virtual machine and in its
NetBeans IDE. It seemed there were almost as many talks about using NetBeans for
Ruby and Rails development as there were about using it for Java development. TextMate
finally has some real competition for the Rails community.
Dancing robots and other distractions
It wouldn't be JavaOne without toys. Sun was hyping RoboSapiens, those
funky dinosaur and humanoid robots the kids were clamoring for last Christmas.
Apparently each one includes a Java virtual machine. The VM in the
off-the-shelf robots is locked away and inaccessible. However, a limited
number of programmable robots with unlocked VMs were on sale at the show.
There was also an informal contest to see who could make the robot do the most
interesting thing. At the opening keynote, they said they might put the winner
on stage on Friday, but instead we got a canned demo of the robots dancing --
poorly.
The problem with an at-show contest is that no one who actually goes to
JavaOne has any time to seriously participate. What little time isn't spent in
sessions or on the show floor is spent waiting in line to get into sessions or
to pick up lunch. Actual hacking time is at a minimum. This problem was also
apparent in the Virtual Flying Dukes competition. This contest required
developers to use the jMonkey Engine (jME) to build three-dimensional avatars
that could catch a virtual t-shirt launched from a virtual cannon. (This
replaced the much more interesting non-virtual cannons and
catapults from previous years.)
Despite a $5000 first prize, there were relatively few entries, and most
attendees felt that they could easily have surpassed the winning entries with
just a day or two of uninterrupted hacking time. Of course, uninterrupted time
is exactly what JavaOne doesn't give you. With the exception of the keynote
slots (especially the boring corporate keynotes in the middle of the show)
there were usually at least three or more interesting things going on at any
one moment.
Toy-wise, though, the real hit of the show was not a robot, virtual or
real. It was the Sun SPOT, a small programmable sensor that runs the Java 2
Micro Edition CLDC as its native language and operating system. It includes a
temperature sensor and an accelerometer so you can tell in which direction the
spot is moving and how fast. You connect to it over USB or wireless. It can
control other devices such as robots and doors. It's a little expensive right
now (over $500 apiece) but pricing is likely to come down if it ships in
volume. A lot of neat Sun SPOT projects were demonstrated throughout the show,
and more were being discussed and imagined in hallway conversations. Overall,
the Sun SPOT seemed a lot more useful and less limited than a toy robot or yet another virtual world.
Wrapping up
This year's JavaOne was the most exhausting conference I have been to in a
while. It started at 8:30 a.m. and didn't stop till shortly before midnight.
(Next year I'm definitely staying at a closer hotel.) However, there's a reason
the conference runs so late: there's a huge amount of new and exciting stuff happening with the Java platform and related technologies, and JavaOne is where it all hangs out.
No one person could have seen everything at this show, and I was no
exception. I didn't get to even half of what sounded interesting, and probably
saw less than a quarter of what was going on. I really wanted more
time for BoFs, the RedMonk Unconference, the JavaME and TV tracks, more Ruby,
and just exploring the show floor, but there are only 24 hours in a day and
there were usually about 24 things going on in parallel. At times, JavaOne felt
like a live-action demo of multithreaded program.
Based on the energy at the show, the Java platform is as strong as it has
ever been, and it's growing. Despite its cross-platform appeal, the Java
platform was for a long time a fairly closed ecosystem. What this show really
demonstrated is that this is changing. The platform is opening up to new
communities and addressing new use cases. The GPL license will finally allow
it to be taken seriously for Linux development and perhaps begin weaning that
community off of C and Mono. Equally important, the Java virtual machine is
opening up to scripting languages like Ruby, Groovy, and Scala. This will
enable it to enter new problem domains that were previously the fiefdom of
scripting languages like Python and Perl. Finally, JavaFX Script is at least a
tentative step into the rich Internet application domain pioneered by the Java
platform but more recently colonized by Flash and Ajax. If Sun had done this
five years ago, Flash might be a minor player in the Web today.
As someone who's always found clients to be more fun than yet another
database back end, it's reassuring to see that Sun has finally rediscovered
the client. The Java platform's reach is longer than ever, and the future is looking bright indeed.
Resources Learn
Get products and technologies
Discuss
-
Client-side Java programming: Discuss the new Swing Application Framework, Java 2D, JavaFX Script, and more in this developerWorks forum.
- "JavaOne 2007, #2: Making Web Apps Easy" (Eric Armstrong, Artima Developer Weblogs Forum, May 10, 2007): Reports on Charlie Nutter and Tom Enebo's talk about the benefits of combining technologies like JRuby, Rails, NetBeans, and Glassfish.
-
developerWorks
blogs: Get involved in the developerWorks community.
About the author | 
| | Elliotte Rusty Harold is originally from New Orleans, to which he returns
periodically in search of a decent bowl of gumbo. However, he resides in the
Prospect Heights neighborhood of Brooklyn with his wife Beth and cats Charm
(named after the quark) and Marjorie (named after his mother-in-law). He's an
adjunct professor of computer science at Polytechnic University, where he
teaches Java and object-oriented programming. His Cafe au Lait Web site has become one of
the most popular independent Java sites on the Internet, and his spin-off
site, Cafe con Leche, has become
one of the most popular XML sites. His next book, Refactoring HTML, will be
published by Addison Wesley later this year. He's currently working on the XOM API for processing XML and the Jaxen XPath engine. |
Rate this page
| |
