Software “Architect”? Dream on, code monkey.

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.

Enough with the link blogs already!

Apparently I’m guilty of programming language discrimination.

We’ve come such a long way…I can’t recall the last time I had a tabs v. spaces argument.

Great hair is eternal.

(tabs considered harmful)

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!

Helvetica, like the font, is boring.

*** UPDATE: See my comment below ***

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.