Skip to main content

A Beautiful Mess

Posted by editor on May 20, 2008 at 6:26 AM PDT


JavaFX or Swing or something else? Yes.

Considering the user-facing focus of JavaOne 2008... JavaFX demos, Neil Young's archives on Blu-Ray, On2 video codec, phone stuff, etc... one might expect the desktop developers to be delighted to be back in the spotlight. But in fact, there's a distinct grumbling in several quarters, and it gets back to an interesting question:

If JavaFX is meant for designers, then have you forgotten about us desktop developers?

The sense that existing Swing developers aren't completely comfortable with JavaFX has popped up in a few public places recently. For example, consider the harsh words that java.net ewin shared on last week's poll:

For now FX gives a clear message. Sun has once again given up competing at the desktop. The previous filth rich client marketing bushwah failed spectacularly (guess why ...), the framework thing didn't take off (guess why ...), so for the moment Sun decided they don't want to push Java for serious desktop applications any more. Instead it has to be something for the web, artsy-hippy people: FX.

But is this the case? fabriziogiudici counters that the new technologies for JavaFX will also be exposed to Java, in forms like the Scene Graph, or the promised Java Media Components. He writes, "So JavaFX is not a "distraction" of resources from the desktop, it's just the opposite."

One of the most prominent Desktop Java developers is Substance creator Kirill Grouchnikov, and to get some answers, he took his questions about Swing and JavaFX to the source. In Swing, RIA and JavaFX - interview with Amy Fowler, he talks to Swing co-founder and Sun senior engineer Amy Fowler about the audience for JavaFX, its potential for tool support, third-party component libraries for Swing, the use of Swing as a "UI virtual machine" by dynamic languages on the JVM, and more. Amy has also blogged about the interview, saying that Kirill "always asks us insightful and often difficult questions."

So, if you're ready to decide for yourself where we're going with JavaFX and Swing, check out what Kirill and Amy have to say.


Also in Java Today,
John Rose is updating the status of JSR 292, "Supporting Dynamically Typed Languages on the Java Platform". "After a successful meeting at JavaOne, the JSR 292 EG (expert group) has published its EDR (early draft review) for the invokedynamic instruction. This draft will be updated from time to time (in response to your comments), until August 17, which is the end of the 90-day review period."

The Aquarium is noting that "Hands-On Labs from JavaOne 2008 are available online.
You'll find detailed steps for the "Plug into GlassFish V3 with JavaServer Faces and jMaki" lab which is what inspired the "Admin Console Plugins in GlassFish v3" screencast.
There's a total of 27 labs fully documented with detailed steps and archives. Here are the GlassFish-related ones..."


Along with blogging about Swing, Kirill's also been thinking about how to manage one-person open-source projects. So, today's Weblogs section featuers his summary blog
Party Of One: Surviving A Hobby Open Source Project, he shares "things I learned from being the only developer on a few open-source projects.:

Kohsuke Kawaguchi introduces a Key format conversion library from PuTTY to OpenSSH.
"I wrote a small Java library that converts a ssh key file in the PuTTY format into the OpenSSH format."

More than a week after then end of the conference, Joshua Marinacci has finally recovered enough to brain-dump his impressions, in
JavaOne Exhaustion (with links!)
"So another JavaOne has come to an end. This time I think I finally tried to simply do too much. I'm lucky I didn't get the Moscone flu. Still, all in all, I think we had a good showing."


One often unanticipated vector for security attacks on web applications is the possibility that a user could hack the GET or POST request to send unanticipated or invalid data to the application. In our Feature Article, Eric Spiegelberg introduces techniques for
Securing Your Web Application Requests. In the article, Eric shows how to use JSTL's URL encoding and a servlet filter to obfuscate or even encode parameters in each direction to thwart parameter-hacking.


In today's Forums,
billp offers help for phoneME performance work in
Re: Using profiling tools on phoneME Advanced?
"Profiling pMEA using NetBeans requires some new native libs and some minor changes to NetBeans itself. We were hoping that these changes would get rolled into the 6.x official releases of NetBeans but unfortunately that didn't happen. However, I've put together a cookbook along with some zip files that should allow you to profile with NetBeans 6.0. See the twiki entry here."

chihiro_saito is trying to get Blu-Ray Java to act as a server, in
Any success on ServerSocket for PS/3?
"Wondering, has anyone succeeded in getting a plain java.net.ServerSocket up on the PS/3? I can create it fine, but it doesn't seem to be accepting, or responding to, the incoming request when I open from another machine a socket to the IP address obtained from PS/3's System settings -> System info section. Also, InetAddress.getLocalHost() on PS/3 just returns the loopback address. Firmware v2.35. Outgoing connection has been working..."

Finally ankitmittal000 would like some porting guidance in
start phoneME on win mobile.
"I intend to port phoneMe feature software on Windows mobile. Initially i want to port CLDC and MIDP so that i can run some UI demo midlet. Can somebody help me in how to start the process of porting and what all needs to be done so that i can port CLDC and MIDP completely? Also i want to know that do i need to put some platform specific porting for native calls on windows mobile? But first please tell me detailed explanation about the make file which will be needed for porting CLDC and MIDP on win mobile."


Current and upcoming Java
Events
:

Registered users can submit event listings for the href="http://www.java.net/events">java.net Events Page using our href="http://today.java.net/cs/user/create/e">events submission form.
All submissions go through an editorial review before being posted to the
site.


Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of java.net it will be
archived along with other past issues in the href="http://today.java.net/today/archive/">java.net Archive.

JavaFX or Swing or something else? Yes.

Comments

JavaFX is a huge push forward for Java on the desktop. First, all of the power behind JavaFX is found in Java projects like the SceneGraph project. For those who haven't hungrily devoured Haas & Guy's "Filthy Rich Clients" book, the SceneGraph project is the next incarnation of Haas' animation framework that does all kinds of Apple-esque animations. Plus the SceneGraph Effects subproject is something I've been following for months now (we need the hardward support for Macintosh to be finished already!) and it is pretty sweet. And it's all Java. And it's something that Java programmers can use whether they use JavaFX or not. I do agree that there is more that can be done to enrich Java on the desktop. However, (a) much of the technology that supports JavaFX in the browser translates directly to Java on the desktop (the notable exception being bindings -- argh!!!), (b) all the attention to make Java beautiful and responsive spans browser and desktop, and (c) the realization by Sun's senior managers that there are huge opportunities for Java as GUI platform. I definitely want more resources devoted to desktop Java. And Sun investing in JavaFX is a step in the right direction.

JavaFX isn't attracting anyone yet because it isn't a dependable, consistent language. Most artsy web designers haven't even heard of JavaFX. The ones that have don't use it because the tools don't exist. JavaFX suffers from premature exposure, and although the language itself might be great, the supporting tool chain just is not there. I want JavaFX Script to succeed, but it won't go anywhere until those graphical tools exist.

fabriziogiudici wrote What I don't understand is the huge amount of FUD that is being made by some people. I am sorry to say, but the FUD is coming from Sun.

For more than ten years Sun is simply lying through its teeth when it comes to the desktop. It is an endless stream of broken promises. Every Swing, AWT, Java2D, Java3D, JMF, JavaSound, JavaComm, USB etc. bug is a broken promise. Every half-done, unfinished, abandoned method or API is a broken promise. Every incoherent, incomplete omitted piece of documentation is a broken promise. Every missing bog-standard desktop feature is a broken promise.

We are talking about thousands of broken promises. And you have the nerve to write the following? You might not trust about Sun's delivery, but at least the message from Sun is VERY CLEAR: Oh yes, the message. Every few month Sun changes its desktop strategy, breaks some more promises. Messages from Sun are worth nothing. Actions speak louder than words. What actions? See below: 1. We're committed to the desktop. Oh yes, so committed that Sun didn't manage to ship a decent file chooser (not rocket science) within the last then years. Or that it took ten years to get a (broken) way to access the system tray.That is the real message. And that real message was and is widely understood by desktop GUI developers.

Sun has to turn to the artsy-hippies, because they have burned so many bridges and lost so many goodwill with normal developers. 2. JavaFX is targeted to designers who prefer the declarative way. As I wrote, Sun is now trying to address the artsy-hippy people. On a bad day I would have called them dope-smokers with Photoshop. Maybe they are more easy to convince that a bug is not a bug. 3. But Swing is going on as usual for developers.That is not a promise. That is a threat! Because Swing needs much more work and attention then it usually (the last ten years) got from Sun. 4. JavaFX is going to bring a lot of new APIs for the desktop that will be usable by the Java language as well. Yo, we might (might, not will) get a freaking scene graph API and others (now doubt they will only be half-finished if we get them). Now, please explain in simple words how that is supposed to fix basic Swing problems? Only because Sun throws more bugs at us doesn't mean the existing ones will go away. And this shouldn't sound too strange, since the message "one platform, many languages" has been made clear for years and it's proven by the fact that we have dozens of "new" languages running on the VM, such as Groovy, JRuby, JPython, Scala. In particular, Sun's committment to Groovy, JRuby and JPython made nobody think that they are deprecating the Java language. I don't care what other languages Sun does. I simply care about yet another distraction from Sun's essential desktop problems. In spite of this clear communication, people are:

* Asserting that Sun is not committed on the desktop

How should we, after thousands of broken promises, and yet another distraction? Sun has ADHD when it comes to the desktop. Sun might think it is doing clear communication, but it shows nothing else then erratic behavior. * Asserting that JavaFX is just vaporware I don't care about FX, I care about the resources this pointless exercise eats up. * Asserting that Sun is focusing on JavaFX and abandoning Swing How else should one interpret that (a) resources are thrown at this FX junk, instead of fixing decade old Swing bugs, (b) Amy talks about demoting Swing to some plumbing tool, (c) Sun's marketing department is running amok about FX, (d) you call bog-standard desktop application developers a minority (see below)? Men, are you realizing that the world if full of people with different ideas than yours and that a corporate market strategy must be focused on broadening the target? Especially when you are in a minority position? Thanks for confirming that Sun has decided the normal desktop is a minority thing.

So yes, message received. Swing developers are a minority in the eyes of Sun, and Sun won't wast money on a minority. We should be grateful that we might get some crumbs falling from the table of the artsy-hippies. We will have many new APIs, period.But for deities sake, WE DO NOT WANT THESE! We want that the old ones are first of all completed and fixed. Got it?

Fabriziogiudici whats annoying us isn't having more choice - It's that Sun clearly doesn't have the resources to be developing two UI frameworks at the same time. I've seen no roadmap for the duplication of the same functionality into Swing. On the contrary the two key upcoming JSRs for Swing have suffered major setbacks directly BECAUSE of JavaFX, FACT not FUD.

Whats missing is the communication from Sun. What are the plans? Will beansbindings, timimingframework, SAF continue despite being duplicated by JavaFX? What we'd like to see is Swing evolve from it's frozen 1.2 internals with the kinds features you're putting into JavaFX rather than "going on as usual". We'd like a level playing field with the likes of Flex more modern languages. Continue to freeze us out and we'll eventually vote with our feet. The features Swing gains from JavaFX are largely useless to the vast majority of existing Swing desktop apps Movies? Transparent Windows? 2D Scene Graph? WTF

Sweeping statements like "every application will be an RIA (JavaFX) one" and "JavaFX is for designers not developers" just feed these fires in the absence of any information.

From our standpoint you promised us bindings, frameworks etc.. and then stop the work without warning, leave use six months without news, support or progress. And then announce a whole new language with these same features only we can't actually leverage from our existing Swing apps. We also see is Sun hemorrhaging key employees from an already under resourced team who clearly didn't agree that more freedom of choice never hurt anybody. Enjoy what exactly? I'm not a designer.. Enjoy the wait for the Swing team to work on something with some practical use instead of eye candy? Enjoy more resignations and abandoned APIs to follow? what is so very wrong in the client side team?

Don't you have to be very careful about quotes like "JavaFX is meant for designers"? "JSF is unusable without tooling support" was hugely damaging. Begs the question so why keep bugging us Java developers about JavaFX then? go see if the LAMP crowd says if it has any legs.

One of the things that attached me to Swing is there is no obvious cross platform UI standard, there's dozens. GTK, TkWindows, Qt, MFC, Silverlight, AIR, Flex, XUL, XAML, WinForms. Once upon a time it made sense to divide developers with your propertiery UIs. But these days most of these are ISO or open sourced. A large chunk of why Ajax webapps have been so popular is their ease of distribution and cross platform reach. Not their ease of development and special effects. Swing despite it failings offered a single UI framework that worked well enough on the most platforms - thats what I want, I don't want to port code, or re-learn lots of frameworks I want to be able to reuse our UIs and know it'll still be supported in six months time.

So any suggestions that Swing isn't up to the job anymore and should be supplanted rather than re-engineered is a bitter pill to swallow.

I wish sun will get this simple truth: It is not fun coding GUIs. Its has been almost 10 years since delphi, and still building a GUI app in delphi is faster than any swing (even if u throw some frameworks at it) development. No the "declarative" way of building GUI's is being forced on us.

The discussions I've read in these days are paradoxical. I mean, I expect a huge deal of skeptical attitude towards JavaFX because is not here. I second this attitude which sounds very practical for a decision maker. I myself won't start anything TODAY with JavaFX that is not experimental in nature.

What I don't understand is the huge amount of FUD that is being made by some people. You might not trust about Sun's delivery, but at least the message from Sun is VERY CLEAR:

  1. We're committed to the desktop.
  2. JavaFX is targeted to designers who prefer the declarative way.
  3. But Swing is going on as usual for developers.
  4. JavaFX is going to bring a lot of new APIs for the desktop that will be usable by the Java language as well.
And this shouldn't sound too strange, since the message "one platform, many languages" has been made clear for years and it's proven by the fact that we have dozens of "new" languages running on the VM, such as Groovy, JRuby, JPython, Scala. In particular, Sun's committment to Groovy, JRuby and JPython made nobody think that they are deprecating the Java language.

In spite of this clear communication, people are:

  • Asserting that Sun is not committed on the desktop
  • Asserting that JavaFX is just vaporware
  • Asserting that Sun is focusing on JavaFX and abandoning Swing
  • etc...
and it's appalling to see that each of these assertions contradicts the others. Men, are you realizing that the world if full of people with different ideas than yours and that a corporate market strategy must be focused on broadening the target? Especially when you are in a minority position? We will have many new APIs, period. If they will work or not, will be buggy or operational, etc... we can't know today - we have to wait for the first pre-release. So any discussion at this point is based on void. These APIs will be available from Java AND JavaFX. Programmers that like Swing will continue on working on Swing. Programmers that are bored with plumbing code will have the opportunity to use JavaFX. Designers will be offered a way to enter the Java-the-runtime world. Having more freedom of choice never hurt anybody. Enjoy.