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.

This is a real XXXX in the XXXX…

UPDATE: I withdraw this comic. See my apology and second attempt.

In next week’s episode, James Gosling joins 37 Signals as a Rails evangelist!

I spent the last few days profiling and optimizing one of our app’s primary GUI screens. Here are some observations:

1. Our app includes a built-in diagnostic tool that logs every server call. We can bring up a dialog and watch the calls as they occur. For our first optimization, we moved one of these calls off the EDT to a SwingWorker. Although the call itself only took 10-30ms, it was called often enough to introduce noticeable sluggishness. Having built-in diagnostic tools is priceless, because you can monitor what is happening behind the scenes.
2. NetBeans includes a decent profiler, and the price is right: $0. Despite using IDEA for most coding, I always turn to NetBeans for profiling. IDEA could really use an integrated profiler.
3. Having a super fast PC is helpful, because profiling is extremely taxing on your system. I don’t have a super fast PC, which makes the profiling experience painful and tedious.
4. Despite the pain of a slow PC, profiling is very rewarding when you find a problem and fix it.
5. We found several hot spots — NetBeans does a great job making these obvious. Each time we’d fix one issue, we’d run our scenarios again and find the next most critical issue.
6. When optimizing, start with the worst hot spot and work your way down the list. A “hot spot” might mean a method is called once and consumes 13 seconds, or perhaps a method only takes 3 milliseconds but is called 800,000 times.
7. Profiling is always surprising. One bottleneck was caused by an obvious programming error, and that error has been in our code since 2005. Ouch.
8. You will hit dead ends. For example, one hot spot involves a small helper class that is executed tens of thousands of times. Unfortunately, the code is mutable with a wide open public API, making optimization quite hard. If this class was immutable and had fewer methods, I’m sure I could optimize it further.
9. I try to fire up the profiler and spend time looking for problems before customers complain about bugs. I tend to focus on either runtime performance or else memory leaks, but generally not both in the same session. I may spend a few days each month focusing on one or the other.
10. Optimizing always involves risk. Fixing one thing may introduce a new bug, so proceed with caution. Mitigate this risk by focusing on the most critical bottlenecks first. Optimize enough to make these bottlenecks go away, but don’t go so far that your code becomes unmaintainable.
11. I found that after optimizing, the code is often cleaner than before. This might seem counter intuitive, but spending time meticulously analyzing a particular method line-by-line often gives you insight into better implementations. It think it is wrong to blindly assume that all time spent on optimization and efficiency necessarily leads to cryptic code.

I suck. After my late night drunken IDEA is Now Enterprisey post, my faithful readers let me know just how wrong I was. Here are the top ten reasons why IDEA is NOT Enterprisey:

1. IDEA is better than NetBeans. Sure, NetBeans includes a free profiler (which I really like and use all the time), and NetBeans is better at Swing GUI layout (who cares), but IDEA is better for stuff I care about…like coding. If IDEA was worse and still cost a lot of money, it would be Enterprisey. But they have the quality to back up the price.
2. IDEA is better than Eclipse. Eclipse has a lot of plugins, which is fine unless you care about stuff like usability.
3. IBM Rational Application Developer for WebSphere costs $2290 for one developer and expires in 12 months. If you want the license that does not expire, that costs $4240 per developer. For a single floating license, you’ll pay $7430.
4. More on the previous point. IBM Rational Application Developer for WebSphere is a bloated*, slower**, more resource-intensive*** franken-IDE built on top of Eclipse, yet costs up to $7430. Ouch. That, my friends, is Enterprisey.
5. Enterprisey products never have good keyboard navigation. IDEA does.
6. Really smart people all left Java to use Ruby, Groovy, and perhaps Scala. Of those who remain, the top few percentile still prefer IDEA. There must be a reason why all of these smarties like IDEA.
7. IDEA completely changes its project file format with each major release. They also keep tossing out and rewriting the project management GUI. Enterprisey products are far less volatile, demonstrating that JetBrains would rather fix and improve their product versus hanging on to garbage for years just to appease some boring IT department. (think Apple versus Microsoft here)
8. IDEA’s bug database is public, definitely not very Enterprisey of them.
9. Carpenters and mechanics buy some of their own tools. Somehow this makes IDEA non-Enterprisey.
10. As Mark V. pointed out in an Email, you can get a free IDEA license by speaking at the St. Louis Java User’s Group. Which reminded me…that’s how I got my current IDEA 6 license. Damn, I’m a cheap bastard.

My wife just brought me ice cream, so I’ll wrap this up.

In summary, I apologize for the last post.

Footnotes

* - I’m just making this up
** - could be, I don’t know.
*** - how would I know? You think I’m paying $7430 to find out?

It’s official, JetBrains raised the price on IDEA. While they claim they have not raised prices in 5 years, this is not the complete story.

Remember back in the good ol’ days when you could count on a significant personal license discount every Easter? I’m pretty sure that didn’t happen last year.

And speaking of price increases, it used to be true that when you bought IDEA, you got the next major upgrade for free. Then, you had to pay for the version after that. But now it seems like you have to pay for every single upgrade if you wish to stay current.

And finally, upgrades come more frequently than ever before. IDEA is pretty much a yearly subscription service. So while they can say prices have not changed in 5 years, I’m not buying it. (literally)

Sure, you don’t have to buy every upgrade. But when you wish to move to new versions of other tools, like Subversion, you might have little choice but to upgrade IDEA or move to a new IDE. My biggest disappointment is the observation that IDEA is simply out of my reach…I cannot justify the cost. Thus, I still use IDEA 6 at home and work. Upgrading to IDEA 7 (and beyond?) is not an option where I work. Yearly, costly upgrades for every developer in the department will not fly.

Perhaps if I worked at some giant nameless corporation (you know, an “enterprise”), getting upgrades would be easier. Then again, companies like that already pay a lot more for Rational products.