Test Center review: Java fights Flash (InfoWorld) (摘录)

本文摘录自

http://tech.yahoo.com/news/infoworld/20090209/tc_infoworld/125043

A long time ago, in an ancient world when the Internet was young, the Java language was so hot that Fortune put Scott McNealy on the cover with a superhero costume and the name "Java Man." The cross-architecture power of Java was going to remake the computer world and become the default OS for all of computerdom.

Although Java found a great deal of success in education, scientific computing, and server farms, it never got far on the desktop. The Java applets that could be embedded in any Web site couldn't compete with the smooth animation and anti-aliasing of Flash. Microsoft fought back with dynamic HTML, later reborn as AJAX, and the applet threat to Redmond's Web dominance faded away.

[ See the Test Center's reviews of Microsoft Silverlight 2,Adobe AIR 1.5, and Adobe Flex Builder 3.0. See the special report on rich Internet application development. ]

It's now more than 11 years later and Sun is back to take another stab at owning user-level interaction. The task is harder becauseAdobe has AIR alongside Flex and Flash, all slightly different tools offering some functionality beyond HTML and JavaScript. Flash alone is on its 10th version and comes with more features than ever before. That's just the beginning: Microsoft offers Silverlight, Apple still pushes QuickTime, and there's always the animation fun in AJAX. All of them are competing to be the dominant tool for delivering heavily animated widgets for picky users who presumably want their slick graphics to dance, wiggle, and swoosh across the screen in the process of -- oh, I don't know, sending an e-mail.

Lipstick for Java
Sun is now a bit better prepared for the battle. It has a rich stable of libraries for animation, including the well-regarded Java 2D, developed with Adobe to mimic much of the computational structure of PostScript. This is essential because some suggest that Flash beat out Java applets for Web animation because it offered smooth anti-aliasing. If Java 2D is not enough, there are a huge panoply of open source libraries developed to handle almost any need a programmer might have.

The problem for Sun was how to put this wine in a new bottle. Although the parts were ready for Web artists long ago, artists weren't ready for them. Some savvy artists can write scripting code for Flash, but pure Java requires a great deal more devotion. So Sun created a new language that is little more than syntactic sugar on top of Java. It built something that it hopes Web developers will like and used a new compiler, javafxc, to turn it into Java byte codes for the JVM. Voila! Java with new lipstick.

I've spent several days playing with the new language, and I've come to the conclusion that JavaFX's success and failure will be largely a matter of taste. The new syntax hides some of Java's nerdiest and most insistent requirements, giving the user a bit more freedom to ignore some punctuation. Many of the design details about color and placement can be mixed right into the code, producing something like CSS, HTML, and JavaScriptcombined in one file. There are also a number of built-in functions for handling the most common tasks, such as tweening GIFs or loading a remote file.

This convenience comes with a price: learning yet another syntax and remembering yet another set of ways to structure a Web application. The old keyword "void" is renamed "Void" with a capital "V," but you don't need to type it explicitly when defining what comes back from a function. There's plenty of other syntactic sweets. Collection data structures can be built up with phrases like insert "Fred" before names[3] . I think this could be welcoming for the right-brained, visual thinkers. Much of the dot notation for objects is replaced with more casual sentence-like strings.

After some experiments, I found myself torn. Why didn't Sun use Groovy, a quicker shorthand for Java programming? Or perhaps JavaScript? There are clever hooks between the JavaScript layer in the browser and the JavaFX applets. Or why not plain old Java? I've been wondering whether it was such a good idea for Java programmers to embrace different syntaxes like XML or the Properties file when much of this can be expressed in Java itself. But it doesn't matter -- I'm not the main audience.

Web mixology
In time, the syntax grew on me. The principle advantage seems to be that everything for a page is plopped in one file. The layout objects, the style, and the animation effects are all mixed together in one place. There's no need to page between CSS, HTML, and JavaScript files. Mixing the parts into one file isn???t a requirement -- in fact there are several mechanisms to encourage programmers to split a project into reusable modules.

Is mixing bad? Some devotees of strict separation of functions like Model, View, and Controller will grimace. Separate files for different jobs make it easier to maintain, the devotees of MVC insist. Lumping everything together in one JavaFX file makes it harder to give the CSS file to some designer and the JavaScript file to an AJAX programmer. Yes, that's true. But the integration is so tight that it can be onerous paging between the different files to first give some div an id, then give the id some styles, and then tell the id how to behave. If the code isn't too complex, why not mix them together? There's a chance that the designer will be able to cut and paste enough code to skip the programmer. Then it won't be a question of separating the tasks for the various people because there won't be two different people.

This mix-up isn???t required because the language has ways to separate the work if desired. The skin can be broken off into CSS files for a designer to work through while a programmer works on the scripting. I???m guessing, though, that JavaFX will be much more accessible to designers than JavaScript or some of the other languages. I???m also sure that there will be plenty of debate about the right way to structure an application.

Sun put a great deal of effort into adding JavaFX tools to NetBeans (see screen image). The simplest way to investigate the platform is to download a pile of code that comes wrapped up in NetBeans. There's also a collection of plug-ins that will export graphics from Adobe's Illustrator, Photoshop, and Flash. I think it might be possible for a brave artist to export some art from their favorite tools and create a morphing wonderland in NetBeans. But the average artist will probably need some hand-holding because the syntax of JavaFX is filled with many options that just pop out of nowhere. Only a programmer would think of mixing an if-then statement into a string definition:

var s="The world is {if (date>1492) "round" else "flat"}.";

It's a good thing we got rid of those curly brackets from Java's if-then syntax because then we could use them for something else in the middle of a string.

The artists out there don't need to confront such fun at the beginning because there's plenty that can be done with the simpler syntax. They don't need to wonder about such wormholes in the string definition until later.

Param Singh, the senior marketing manager for JavaFX, told me that Sun expects the early adopters will be largely Java developers and some very savvy designers.

???The tools are clearly in an IDE so you need to be familiar with an IDE,??? Singh said, before explaining that visual tools for designers were coming later, along with tools for developing JavaFX applications for mobile handsets.

I???m wondering whether these tools will also be free or at least much more inexpensive than Adobe???s tools. Programmers have reaped the rewards of the open source revolution and there???s a wide array of free tools. JavaFX could make inroads with young developers if the designer tools are significantly cheaper than Adobe???s.

I don't know if this is enough to capture much market share from Flash, AIR, or any of the tools. Programmers love their ruts. But it will empower Java programmers to take on new tasks, and this may let the language colonize more of the screen. Java programmers with a serious pile of code will be able to distribute it with greater ease.

The old guard
This is why I think the most common users of JavaFX will probably be scientific and financial programmers who need to put a prettier face on their sophisticated systems. Any Java library can be integrated into a JavaFX application, and this makes it possible to put a very smart, fat, computation-rich back end behind the tweening graphics. I can't imagine writing such programs in something like Flash's ActionScript. The tools for developers aren't as ready to handle big projects. It's nice to be able to call upon the multithreaded world with profiling tools.

Perhaps the real leverage will come as the hard-core Java folks push for better deployment options. One programmer, for instance, showed how to integrate JavaFX code with the drag-and-drop model for the desktop. This code will deploy directly through Java's Web Start, making it possible for someone with the latest version of Java to just click on an application that will accept files from the local computer. It's a pretty nice deployment model for a corporation, a free open source project, or anyone that's not planning on charging directly. JavaFX could end up being a good replacement for Swing by giving Java developers a chance to build up their UI out of HTML-like components instead of the Swing versions. JavaFX is not just a way to make a Web page dance; it has all of the right mechanisms for deploying desktop applications.

I think many designers will also enjoy building upon the hard work that???s gone into Java over the years. The JVM is very fast these days, thanks to the demands of the server-side installations that can???t hide behind a cursor that turns into an hourglass. The libraries are numerous and generally well-vetted for security holes. Plus, the latest JVM is installed on 80 million desktops already. These are now capable of handling JavaFX.

The rest of the artistic world may be a harder sell. Adobe makes nice tools for using Flash and AIR, but it charges a pretty penny for them. It may be possible for JavaFX to attract some of the younger, poorer designers who don't have the money to buy into the Adobe stack.

Handicapping the overall success of JavaFX is a bit more difficult. Will it displace Flash, Silverlight, or the others? Not immediately, especially when Microsoft is willing to work so hard on such big-budget extravaganzas like the 2008 Olympics. But I think it has enough meat on the bones to earn some real fans and win a solid niche wherever there's Java code that needs a prettier face and better distribution method. It gives Java another chance to gain some ground on the desktop.