Poll Result: Java on the Desktop Is in Desperate Need of Attention

A plurality of developers who voted in last week's java.net poll consider Java on the Desktop to be the area that most desperately needs attention in 2011. A total of 611 votes were cast, and the poll inspired a discussion that included 11 posted comments...

A plurality of developers who voted in last week's java.net poll[2] consider Java on the desktop to be the area that most desperately needs attention in 2011. A total of 611 votes were cast, and the poll inspired a discussion that included 11 posted comments.

The exact poll question and results were:

Which area of Java/JVM technology most desperately needs serious attention in 2011?

7% (44 votes) - Java EE

25% (155 votes) - JDK (Java 7, Java 8)

31% (192 votes) - Java on the desktop

16% (100 votes) - Java on mobile platforms

5% (29 votes) - Java Web Services

8% (48 votes) - New JVM languages

2% (13 votes) - Other

5% (30 votes) - I don't know

The first thing that stands out for me is: the area that received the most votes is an area that isn't receiving many headlines lately. What is the plan for moving Java forward with respect to desktop applications? Is there one?

Of course, the concept of "the desktop" is a moving target -- it changes as hardware and new devices are developed. What's the desktop today? A screen on a desktop or laptop? An iPad? A mobile phone? Is there really a distinction between the desktop and mobile devices? Some people think not; others strongly disagree.

jdevp2 commented:

If we add Java desktop and mobile , it's 47% as of now so people do care and like client Java.

And osbald wondered

Why have separate options for Java desktop and Java mobile? I thought the whole point of the new JavaFX effort was to address all the screens of your life. I don't want two unrelated UI APIs to learn & maintain and lets face it theres little chance of reviving Swing anymore as was made abundantly clear at Javaone - thanks Amy.

Some people were surprised by the number of votes "Java on the desktop" received. spullara commented:

I'm very surprised at the number of votes for "Java on the desktop". Why do people care about this?

sproketboy was both surprised and pleased:

Wow I was not expecting so many votes for Desktop Java. Makes me happy. I'd love to see improvements in this area. Like Java3d support.

aleixmr and steven_reynolds talked about their companies, products, and the problems they face going forward, in the absence of a continued focus and development of Java's capabilities on desktop platforms. Here's aleixmr's situation:

we develop business aplications for our customers, orders, stock control etc, for us is a MUST having a ui toolkit for the desktop. For us is a pain developing such an aplication with web tecnologies, we did via swing applets and hessian protocol and I must say it's amazing, fast and realiable. I woudldn't develop an application like this via AJAX/html/css in any way !! one must use technologies for their needs, not as a techy fashion, every tool is able to solve different problems, so living in a web 2.0 era does not mean we have to neglect desktop java apps !!

makes libraries and end user applications to draw complex petro-physical data. Java really works well, but could be so much better with just a little attention.

For example, some of our customers say that they won't touch Java because printing is broken. And it's true that printing has some issues that seem to bite really hard out of all proportion to their conceptual simplicity.

Another concern that we have is that the Oracle Engineering team seems to be saying that Graphics2D drawing is dead going forward, and that the scene graph technology will replace it. That would be a huge hit for us, and we'd like to argue against. In particular, we have displays with huge numbers of objects (think Seismic data sets with 500 GByte of data being drawn on the screen). Simply thinking that we can construct a scene graph that has all the objects instanciated is just not going to work for our use cases. Our experience is that immediate mode graphics (draw and forget) has some extremely important scaling advantages.

This brings me back to jdevp2, who commented:

I'm just curious if the result of this poll will be sent to Oracle. If not, the poll doesn't serve too much purpose.

The results of this poll can be sent to some people at Oracle. But much more is needed. I believe Oracle will listen to the argument that failing to attend to the needs of Java software vendors for whom desktop applications are a key component of their products is a serious problem.

The results of this poll, and especially the comments, are a sign that an almost exclusive focus on moving only Java EE and the JDK forward will cause considerable damage for broad segments Java community in the future. If Java on the desktop ceases to be a viable option for those whose products depend on it, Java itself will ultimately suffer the consequences as those vendors move to other platforms.

Java Today

Last week's International Oracle User Group Committee (IOUC) Summit at Oracle HQ was a high point of the past year, for a number of reasons: * A "quorum" of Java User Group leaders, several Java Champions among them, were in attendance (Bert Breeman, Stephan Janssen, Dan Sline, Stephen Chin, Bruno Souza, Van Riper, and others), and it was great to get face time with them. Their guidance and advice about JavaOne and other things are always much appreciated...

We are pleased to announce the immediate availability of the Asynchronous Http Client (AHC) library version 1.5.0. This version includes: * 100-Continue support. * New very simple SimpleAsyncHttpClient Fluid API[6]. * Performance improvements and optimizations...

In addition to mulling over nulling[8] in the try-with-resources statement, the JSR 334 expert group has decided to slightly amend the syntax of try-with-resources statement: an optional trailing semicolon will now be allowed to terminate the list of resources. Previously, a semicolon could only be used as a separator between two resources as in...

Spring Roo is a lightweight productivity tool for Java™ technology that makes it fast and easy to develop Spring-based applications. Applications created using Spring Roo follow Spring best practices and are based on standards such as JPA, Bean Validation (JSR-303), and Dependency Injection (JSR-330). Roo offers a usable, context-aware, tab-completing shell for building applications...