Skip to main content

Follow Me

Posted by editor on September 19, 2006 at 5:48 AM PDT


The era of asynchronicity

I'm coming around to the opinion that the best thing in Java SE 5 isn't annotations (and for darn sure it isn't generics or autoboxing), but rather the inclusion of the java.util.concurrent package for concurrent programming. More and more, I think we're seeing pressures that are combining to make a simple, synchronous approach to programming increasingly untenable, if not utterly unrealistic. Probably the big two pressures are the increasing commonality of multi-CPU machines and multi-core processors, and the increasing use of high-latency network calls, now that seemingly every new app is either a web app or a thick client that makes network calls.

Both multi-processing and remote calls are poorly suited to the "single synchronous thread" style of programming. Code that way and your application will ignore half (or three-quarters, or seven-eights...) of the processor capability available to it. It's even worse when you make a network call and block on it. At least Swing developers know when they've screwed this up: the app refuses to repaint until the call returns. For the webapp, it's just a longer delay getting a result page, something that users are increasingly less willing to tolerate.

More and more, you need to think asynchronously: put some work in a thread and send it off, letting the OS potentially put it on another core or processor. This means that your application has to live on in some stable state while the request is processing, and properly deal with the return value when it comes in on the other thread. Some of the concurrent package's classes, most notably Future and its default implementation FutureTask, make coordination of asynchronous calls easier to manage.

Todays Feature Article takes on the challenges of latency when using web services. Young Yang describes the asychronous answer in Asynchronous Web Service Invocation with JAX-WS 2.0: "JAX-WS 2.0 comes with one effective solution to this problem: asynchronous web service invocation, with which a web service client may interact with a web service in a non-blocking, asynchronous approach. In this article, we will provide an exposition of this technology with examples built upon the reference implementation."


When you think of the synchronized keyword, you probably think of concurrency, and that's the problem with a new version of the closure proposal, according to Rémi Forax. In Synchronized or confined, featured in today's Weblogs, he writes: "A new version of the closure proposal has been post at the end of this week by Neal Gafter and proposes in section 3 to tag parameter with a special keyword to differenciate between synchronous and asynchronous closure.
For me this section contains two flaws, the first one is that the keyword used is synchronized, the second one is to not recognize that such feature can be useful in other contexts than closure."

Gregg Sporar checks in with a round up of
JavaZone 2006:
"Oslo is beautiful and I saw some some good sessions, but as usual, the best part of attending a conference was the people I got to meet."

Finally, in Open quality metrics and processes, Konstantin I. Boudnik writes:
"Despite the differences between business models, development processes, functional areas of the application, and the languages applications are written in, the quality approaches for them are quite similar and final goal is the same."


Internationalization and localization of the JDK tops the Java Today section.

One of several JDK documentation localization projects, the jdk-api-ja aims to improve the translation quality of the Japanese JDK documentation currently available on java.sun.com.
The project "would like to ask willing Japanese speaking community members to review those translations. There has been quite a lot of feedback on Tiger docs after they were released. Now is a good chance to send your input before Mustang is released!"

Twin Java Specification Requests (JSRs) are under way that will define the new Mobile Services Architecture (MSA), the next generation of the Java platform for mobile devices. The SDN article The Mobile Service Architecture Specification says "ultimately, JSRs 248 and 249 will define a comprehensive structure of APIs aimed at facilitating development and deployment of the widest possible variety of applications, in a form that will be easily portable across the broadest possible spectrum of mobile devices."

The ninety-forth ssue of the JavaTools Community Newsletter is online, and in an odd bit of timing, it has no graduations to announce or new projects to welcome to the community this week. What is does have is a round-up of tool-related news from around the web, and a Tool Tip collecting tools of particular interest to developers moving to Mac OS X.


Does the JDIC project have too many Latent Subtle Windowsisms?
In today's Forums,
robross is working on the Mac version, and in working out analogous cross-platform behavior, he has a
Question for implementors of native system tray on Windows:
"If you worked on the native code in JDIC to support the system tray features on Windows, I would like to ask you some questions. I'm looking at implementing this on the Mac. There are some areas where there may not be a one-to-one correspondence of features possible between Mac and Windows (or other platforms.) For example, on current versions of Mac OS X, there is no "official" support from Apple for providing access to the top-right area of the menu bar, to install MenuExtras as they are called. (But there are well-known work-arounds that are in use by many commercial third-party applications.) This area on the Mac is not an exact substitute for the system tray area on Windows. Some of the system tray features of Windows can actually be implemented fairly easy in the Mac OS Dock, but this is a slightly different use than the taskbar in Windows."

brian10 is getting deeper into JavaHelp and is asking for some
Authoring Tool Recommendations:
"We recently completed a swing application in which we created our JavaHelp helpset by authoring an XML document and using docbook's javahelp.xsl for transformation. As a developer, I loved the ease with which this allowed us to generate the helpset. For version 2, however, our helpset will grow substantially and authoring via an XML document may not be realistic. Therefore we are about to begin evaluating tools that offer a more robust means of authoring the help document. RoboHelp currently tops the list because it is a familiar name (although no one on our team has used it)."


In today's java.net
News Headlines
:

Registered users can submit news items for the href="http://today.java.net/today/news/">java.net News Page using our
news submission
form
. All submissions go through an editorial review before being
posted to the site. You can also subscribe to the href="http://today.java.net/pub/q/news_rss?x-ver=1.0">java.net News RSS
feed.


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.

The era of asynchronicity