JDK 5: Learning to read Java again

With Java 1.5 released today, it got me wondering how many weeks it will take until I'm comfortable reading the new language syntax. Tiger's changes are the first major syntax changes to the language in seven years, when features like anonymous inner classes were introduced in JDK 1.1.

After reading Java code on a regular basis over the past six years, I can read Java code quickly. The syntax is second nature. Common idioms have become nearly standardized. And there are only a few common coding styles out there. But Tiger has a lot of new syntax. How long until reading code, like the snippets below, becomes second nature?


Map<String, Integer> m = new TreeMap<String, Integer>();
Code like the above is fairly easy to read. But code like (from java.util.AbstractCollection):
public boolean addAll(Collection<? extends E> c) {
Iterator<? extends E> e = c.iterator();
// ...
is a little less clear. When I first looked at this code, my first question was: Does that compile? A question mark extending an "E"? I'm sure I'll get used to reading code with generics over the next few months. But today, I say, "Huh?"

Static imports
getContentPane().add(new JPanel(), CENTER);
With the above code, I'll first look around for a static final CENTER declared at the top of the program. When that fails, I'll do a text search. And I still won't see CENTER declared anywhere. Then I'll realize it's a static import, a terrible new feature allowed by writing code like import static java.awt.BorderLayout.* at the top of the class. Bleccch.


Annotations probably will be the toughest new syntax for my eyes to scan over quickly and learn to ignore the boilerplate fluff in order to get to the meat of the code. For example, when I read a line like:
public static final void doSomething(int i) {
// ...
my brain quickly skims past the modifiers and sees that it's a method declaration for doSomething.

But this code, taken from the Sun article J2SE 5.0 in a Nutshell, slows me down a lot trying to figure out what's being defined.
import java.lang.annotation.*;
@Retention(java.lang.annotation.RetentionPolicy.RUNTIME) @interface debug  {
boolean devbuild() default false;
int counter();
public class MetaTest {
final boolean production=true;
@debug(devbuild=production,counter=1) public void testMethod()  {
Not only do annotations add more verbose modifiers to methods like testMethod above, my eyes see syntax like:
boolean devbuild() default false;
and stop dead because of this alien syntax. (It defines an annotation type with a default value.)

I'm not saying annotations are bad. I like the concept of annotations. For instance, coding EJBs promises to become slightly easier, and remove the need for running the code through a pre-processor like XDoclet. And when you mark a method with the built-in @Override annotation, the compiler can tell you that you must have mistyped your method public String toStrng rather than allowing you to happily assume you are overriding the toString method in Object -- and spend hours puzzling over why your code isn't working.

Ultimately, I think annotations will allow creative people to write interesting code. For example, Cedric Beust's TestNG uses annotations for unit tests. TestNG's annotations allow you to write unit tests that don't need to extend a class or implement an interface, and allow you to mark a method as being part of one or more test suites rather than having to write separate test-suite classes.

On the other hand, I suspect some developers will go crazy with custom annotations and write a lot of cluttered code. Since annotations allow an unlimited amount of "stuff" inside them, I'm guessing I'll see multiline annotations that bury a method declaration beneath the clutter unless I'm using an IDE with syntax highlighting to point it out. Eventually, though, we'll settle into some standard annotations, and peer pressure will embarrass those who overuse annotations for marginal gain.

And soon, I know I'll get used to reading those annotation tags. My eyes will learn to skim over the annotations, glean the basic meaning, and see the code beneath. Just like the other new language features in JDK 1.5, we'll settle on some comfortable, common idioms so they become second nature. But until then, I'll be spending some time learning to read Java again.

Mozilla Thunderbird RSS reader a nice addition

I finally found an RSS reader that fits my application lifestyle. I've tried a few stand-alone RSS readers in the past, including one that runs under .NET, but none worked well for me.

All the feed readers required me to run a separate application, and most ended up showing me blog entries in such a terrible format that to read them efficiently, I had to visit the web site of the blog. I ended up dumping each of the RSS readers after a couple of days.

My solution was to "subscribe" to RSS feeds by bookmarking them in my web browser and visiting my favorite ones when I had the time. In other words, I was back to the "pull" model, defeating the whole "push" model of RSS syndication.

But Mozilla's new email client, Thunderbird 0.8 now offers RSS feed support. The reader acts in some ways like a regular email account. You can subscribe to feeds, and tell Thunderbird how often to update the feeds. Each feed gets organized under its own folder under the RSS account.

The RSS feed reader is a good start. It really makes sense to integrate an RSS reader into an email client. In fact, I previously was considering dumping Thunderbird and going back to MS Outlook after Dion said he really likes Outlook's NewsGator ($30) plug-in to read RSS feeds.

I have two critiques so far with the Thunderbird RSS reader. First, the formatting of many blog entries often is horrid when Thunderbird is set to display email bodies as "simplified" HTML, which I do to avoid seeing all the advertisements. I'd like to set Thunderbird to display full HTML for RSS entries but "simplified" for all other email. But so far, Thunderbird has one display setting for all accounts. Second, I'd like to be able to configure the frequency of the RSS updates on an individual basis. Some RSS feeds should be updated daily, while others I'd like to have updated hourly. Currently, all feeds are updated on the same schedule.

Even with those faults, the RSS reader is a nice addition to Thunderbird. And this is Thunderbird's first crack at including an RSS feed reader. I should think the functionality will only get better in later releases. Thank you, Thunderbird team.

Fast Web Services for Warfare?

It's been more than a year since Sun Microsystems introduced its Fast Web Services technology at JavaOne 2003. I've been following the status of binary Fast Web Services because of my interest in increasing the speed of SOAP messaging in my projects, and discovered the U.S. military shares my interest.

On Tuesday and Wednesday this week, the U.S. Air Force and the MITRE Corp. held a conference in Virginia on "XML for Binary Interchange: Addressing Machine-to-Machine Interoperability & Tactical and Mobile Computing." MITRE is a not-for-profit corporation managing research centers for the Defense Department and other federal agencies. At the conference Tuesday, Santiago Pericas-Geertsen, one of the inventors of Fast Web Services, gave a presentation on the technology during the public portion of the conference. (Wednesday afternoon featured "military only" sessions.)

The primary Air Force group co-sponsoring the conference is the "AFC2ISR Center" at Langley Air Force Base. The Air Force Command, Control, Intelligence, Surveillance and Reconnaissance Center helps develop technologies that allow reconnaissance aircraft and satellites to communicate real-time battle information to troops on the ground. The conference's primary objective was to help build the Global Information Grid by looking into using XML technologies for messaging "in tactical and bandwidth constrained environments," combining "the advantages of XML with the efficiency of binary-format information exchange."

In order to increase the transmission speed and processing of XML, various standards bodies have developed, or are looking into, binary equivalents to XML technologies, including binary SOAP messaging for faster web services. Not everyone agrees binary XML is a good idea (more on this below). But apparently the military thinks it is. In announcing the XML for Binary Interchange conference, a MITRE conference organizer wrote in an email to the xml-dev mailing list that he was sorry he didn't have time "to engage in a protracted xml-dev discussion. Suffice to say we believe there to be real issues that must be addressed."

If you haven't heard of Fast Web Services, here's some background. FWS is a mix of technologies that attempt to solve the web-service speed problem by using binary equivalents of XML for messaging. Binary XML encoding not only makes SOAP messages faster to transmit over the wire, the format also makes it faster to create and parse the messages, including serializing and deserializing the message from and to programming-language objects.

Fast Web Services uses Abstract Syntax Notation One, developed 20-years ago by the International Telecommunication Union. Sun has worked with the ITU's telecommunication standardization group to create a mapping standard between ASN.1's schema language and XML Schema so ASN.1 can be used as a replacement for XML. Once XML is turned into its ASN.1 equivalent, it can be compressed using Packed Encoding Rules, another ITU standard.

As an aside, anyone I've talked with who has used ASN.1, including two Sun engineers, has made it pretty clear they never want to see ASN.1 again. It is a horrid data language, apparently. But on the positive side, web services developers using Fast Web Services should never have to deal with ASN.1 directly, just like they don't have to deal with the underlying HTTP protocol when writing web services today. The web-service transport layer handles the creation and parsing of the ASN.1 messages.

Binary XML has been a topic among XML developers for more than 5 years. Critics have argued that binary XML
  • Is an abomination that flies in the face of everything that human-readable, self-describing XML was invented for in the first place.
  • Will let unskilled developers create fine-grained web services that will increase server loads unnecessarily.
  • Compressing SOAP XML messages using GZIP works just as well
The first two criticisms are good points, but I don't think they're strong enough to quash a binary web service standard. Web services are here to stay, especially with the big vendors pushing service-oriented architectures implemented through web services. If we can make web services faster in the CPU and faster on the wire, why not? But as far as compression goes, verbose XML is only one reason web services are slow. Creating and parsing the XML, especially if the XML is being deserialized into Java objects, accounts for a lot of the slowness.

Sun implemented a prototype of its Fast Web Services, using a modified version of its Java Web Services Developers Pack. Sun then compared the speed to RMI, RMI-IIOP, JAX-RPC SOAP encoded, and JAX-RPC XML literal. Its tests, running on one machine to eliminate network-connection latency, shows Fast Web Services took 165% the time of RMI, was 2 times faster than RMI-IIOP, and was about 4 to 10 times faster than regular web service calls. You can read Sun's Fast Web Services article for details.

Sun's goals for Fast Web Services are to:
  • Speed processing of web service messages by using a binary format that is faster to create and parse.
  • Speed transmission of web services messages by using a more-compact format.
  • Lower the memory needed for web-service applications, opening web services to limited-capability devices like PDAs and mobile phones (and maybe battlefield gizmos?).
  • Minimize any changes needed to existing specifications (like WSDL).
  • Maintain the interoperability of web services by keeping the message format platform- and language-neutral.
Another major goal is to shield developers from having to know anything about the binary XML format. In Sun's implementation, APIs like JAX-RPC will remain the same. Programmers will continue to write and call web services the same way as today. The transport layer will perform the FWS magic by talking to the server hosting the web service (probably by examining the service's WSDL) and inquire whether it supports FWS. If so, it uses it. If not, it reverts to standard XML SOAP messages.

When Sun unveiled the technology in 2003, it said it should have an implementation available for developers in early 2004 as part of the Web Services Developer's Pack. So far, I have heard no updated plans to release the technology to the public. Perhaps Sun is waiting for the ITU's Study Group 17 to come out with a planned fast web services specification. Rima Patel Sriganesh, a technology evangelist at Sun, said during an online chat in July that she expects ITU's Fast Web Services specification to be completed by next summer.

The W3C also has an XML Binary Characterization Working Group looking into whether a standard binary XML format is desirable. If the answer turns out to be yes, perhaps the W3C will pursue a binary web services standard. In July, the working group published its first draft of use cases describing the need for a binary XML format. The group cited "Web Services as an Alternative to CORBA" and "Web Services for Small Devices" as two uses for binary XML. (By the way, Robin Berjon, the chair of the W3C XML Binary Characterization Working Group, also spoke Tuesday at the military conference.)

It will be interesting to see where fast/binary web services go. Will the W3C come out with its own binary web services specification (and any necessary changes to the WSDL specification to support it)? If so, will those specifications compete or complement ITU specifications? Will OASIS modify its SOAP Message Security standard to work with binary SOAP messages?

The W3C binary XML working group has spelled out a need for binary XML, including binary web services. Members of the ITU have said there's a need for a binary web services standard. And the U.S. Defense Department is saying it needs binary XML and faster web services.

But for faster, binary web services to take off, we'll need clear, compatible standards to ensure interoperability. The W3C will need to work with the ITU to prevent competing standards. And we'll need product companies like Microsoft, IBM, BEA and Sun seeing a big enough market demand to implement those standards as part of their web service stacks.