This graphic illustrates the JDK naming history.

I like “JDK 6u5″ the best. The first number indicates API changes, the second number indicates implementation changes. The “JDK” lets you know this is the development kit, not the runtime environment. This is simple, concise, and easy to understand.

I think the 1.x.0_0y scheme is redundant and confusing because the “1″ and “0″ never change any more.

The whole “Java SE 6″ name just adds to the confusion. Nobody I know says that name out loud. It reminds me of the asinine commercials where the 5 year old kid is singing “I am stuck on Band Aid Brand”, as if a 5-year old would ever say “Band Aid Brand”.

Sometimes, when working with Java 5/6, you still have to call methods from pre-Java 5 libraries. For instance, many of our DAOs are littered with code similar to this:

jdbcTemplate.query(sql,
    new Object[]{ customerId, customerName },
    new int[]{Types.INTEGER, Types.VARCHAR},
    ... );

I don’t like the new Object[] { … }, So today I wrote a static method:

public static <T> T[] array(T... t) {
    return t;
}

And another for primitive ints:

public static int[] intArray(int... i) {
    return i;
}

Thus, I can now write the original code like this:

jdbcTemplate.query(sql,
    array(customerId, customerName),
    intArray(INTEGER, VARCHAR),
    ... );

I have to say that static imports and varargs are among my favorite Java 5 syntax features. Now if only I didn’t have to have special methods to handle arrays of primitives.

Not all projects are skyscrapers.

In fact, hardly any projects are skyscrapers.

A coworker was informed (by a flawed web app) that his JavaOne registration could not be found. And he was unable to login because “his email address is invalid”. Apparently his email must end in something like .com, .edu, or perhaps even .cc to be considered “valid”. (at least according to the JavaOne registration system)

Guess what? .coop is a valid domain name extension. When writing data validators, make sure you don’t reject valid data.

This is a true story. It happened a few hours ago.

I was talking to my 8-year old son earlier today, describing the game Risk. I mentioned that several years ago, I was hooked on a computer Risk game. He was interested in playing, so I found this Java Applet version of Risk. I fired up the page, and a “Loading Java” screen of some sort showed up. While the progress bar slowly inched to the right, I tried bookmarking the page.

But the “Add Bookmark” dialog wouldn’t go away, no matter how many times I hit OK. The browser was pretty much hosed, while the “Loading Java” progress bar slowly inched across the screen. My son uttered the words…

Java is slow.

The game eventually started, I removed around 8 bookmarks (they were all created, but the dialog box was locked up while Java started), and he enjoyed the game.

I confess…I never know what log level to use. Some levels make sense to me:

• SEVERE - the program is about to exit
• WARNING - bad, but I’ll keep on running

Those two levels should always appear in the log, because they indicate bad things that must be fixed.

But the remaining levels are a mystery to me: INFO, CONFIG, FINE, FINER, FINEST. In my opinion, there are too many choices. I believe the overall power of an API diminishes as you add more choices, particularly if these choices are ambiguous and subjective. I believe that no two programmers will interpret the choices in exactly the same way.

I figure I’ll stick with INFO, WARNING, and SEVERE.

Based on every implementation you’ve seen so far, what’s the first thing that comes to mind…

…when you read this news?

I would expect that the 1.6.0_03 to 1.6.0_04 JDK update would contain very minor bug fixes. Instead, it contains a major JAX-WS upgrade from JAX-WS 2.0 to JAX-WS 2.1. Ouch.

*** UPDATE ***

Someone pointed me to Java 6.4 is a whole new Java Release! Also, Rama disagrees in the comments on his blog. I stand by my original opinion that this change warranted more than an upgrade from _03 to _04.

Wouldn’t you know it…all of our web services (well, for one app, at least) broke. Why didn’t they call this 1.6.1?

Sample Code

Here is some sample code someone I work with sent me. This worked on JDK 1.6.0_03:

private void addHttpHeaders(final SOAPMessageContext context,
                            final String userName,
                            final String companyId,
                            final String enterpriseId) {
  //JDK1.6.0 - JDK1.6.0_03
  final MimeHeaders hd = context.getMessage().getMimeHeaders();
  hd.addHeader(USERNAME_HEADER, userName);
  hd.addHeader(COMPANY_HEADER, companyId);
  hd.addHeader(ENTERPRISE_HEADER, enterpriseId);
...

The point is to add custom HTTP headers. On the server, a Servlet filter intercepts these custom headers for some security-related functions.

With JDK 1.6.0_4, he had to change the code to this:

  //JDK1.6.0_04 - switch to JAXWS-2.1
  Map<String, List<String>> requestHeaders = (Map)
       context.get(MessageContext.HTTP_REQUEST_HEADERS);

  if(requestHeaders == null) {
    requestHeaders = new HashMap<String, List<String>>();
    context.put(MessageContext.HTTP_REQUEST_HEADERS, requestHeaders);
  }

  requestHeaders.put(USERNAME_HEADER,
      Collections.singletonList(userName));
  requestHeaders.put(COMPANY_HEADER,
      Collections.singletonList(companyId));
  requestHeaders.put(ENTERPRISE_HEADER,
      Collections.singletonList(enterpriseId));
}

New Way…Old Way…

To make this code portable across BOTH 1.6.0_03 and 1.6.0_4, he ended up leaving BOTH techniques in the code.

My Advice

This is just typical WS-* crap, in my opinion. It’s always very cryptic and complex, not to mention fragile if you try switching from one implementation to another. The promises never live up to the reality.

Thus, I use REST whenever possible.

In no particular order…

1. Fantastic IDE code completion and context-sensitive help, like JavaDoc snippets in tooltips. This “information at your fingertips” greatly reduces the need to context switch between your IDE and external documentation.
2. Powerful profiling tools, like NetBeans, YourKit, and many others, that let you pinpoint memory leaks and performance bottlenecks.
3. Sun provides the JDK source code, making it much easier to learn how libraries work.
4. java.util.concurrent
5. Huge selection of libraries makes nearly anything possible.
6. Jobs, jobs, jobs.
7. Runtime performance.
8. A culture of open source, where nearly any developer tool and API is available under an open source license.
9. Portability.
10. Java is one of the few officially supported languages within Google, in case you ever want to work there.

Weiqi says:

The point? Java has survived in the face of all these public high profile separations. It will live on past this one.

I don’t think “Java” will die because one key engineer left Sun. Weiqi gives a list of important people who left Sun, and of course Java is still around.

Something May Suffer

While Java won’t die, individual initiatives may suffer. For example, now that Peter Ahé no longer works for Sun, who is championing the idea to erase erasure in Java 7? As far as we know, nobody. This makes part of me die inside.

I find myself wondering if maybe Sun would have continued advocating and promoting Jini if Bill Joy, the “father of Jini”, hadn’t left Sun. Who knows.

For a non-Sun example, take a look at Jython. Jython was a revolutionary step towards bringing scripting languages to the JVM — YEARS before today’s efforts with other languages like JRuby. UPDATE: See Alan Kennedy’s comment below. Yet when the Jython creator accepted a job at Microsoft, look how long it took for others to step up and revitalize Jython. It’s damn hard to pick up the pieces when the tech lead leaves.

For yet another example, take a look at the hit HSQLDB took when Thomas Mueller left the project. Again, it took years for another team to pick up the pieces and fully get back on track.

What will Die?

I don’t know. Perhaps nothing. Certainly not Java. But news like this does make me nervous, that’s all I’m saying. Here is why…

• Back in the old days, Sun heavily promoted Java on the desktop. JavaBeans were HUGE in the old days.
• Then came EJB. For many years, Sun lost interest in the desktop. Flash kicked our asses and today dominates.
• Only recently, Sun regained interest in client Java. Probably because key people in Sun strongly advocated this initiative.
• Now one of these key people just left Sun.

Best of all, Chet’s own words:

One of the things that attracted me to Flex, and to Adobe, was a client platform that enables very rich user experiences; transitions, animations, filters, and just darned good-looking UIs are all pretty exciting to this graphics geek.

So…Java didn’t offer enough of those things?

Disclaimer

I don’t know anything. I’m just blogging. You know, writing down my thoughts and ideas. In my opinion, everybody is replaceable.

It is also my opinion that when important people move on, the organization’s focus shifts to reflect the priorities of the replacement people.

And finally, I think it made for a good comic. That’s all.