I am posting this because I was not able to find anything on Net. Even I consider it now to belong into category obvious.

I am working on obfuscation of our project and was bitten by following exception when trying to use the obfuscated JAR:

java.lang.ClassFormatError: StackMapTable format error: bad class index

StackMapTable is feature of Java to provide faster class verification and you cannot configure Klassmaster what to do about it as you can with any proper class.

Eventually I found it works when built locally, but fails with version built by a build server. That helped me to find the culprit.

Solution

We were using old version of Zelix Klassmaster on server due to incorrect default home directory of Klassmaster. After changing path to use version 5.3 it works. It works also with 5.2.4b.

I had interesting mail exchange with my colleague Gilles today. It was about multithreading in Java and how hard is for people to buy into all this.

I would say that the biggest mistake in Java is that it made multithreading to look easy while it is not. Everybody can spawn new threads easily with copy&paste (in the worst case scenario ;-) ). But consequences of incorrect thread-safeness and ignored memory visibility are usually terrible. And it is even worse since introduction of multi core CPUs.

It was about 4 years ago when I was looking for bug in JBoss that caused that an instance of Entity Bean was not saved every 4-6 hours. It took me a week to track it down to incorrect synchronization - two places, one synchronized at instance other at class level. On other side it was rather relaxing - wait till it fails, go through logs, formulate new hypothesis, modify logging in sources, start and wait till another error occurs. Fine for me, but I am not sure about my employer :-) Unfortunately before I could send a patch it was already fixed, so no glory for me :-( ;-) . This example should show how hard it is to fix such a problem and that it happens also to experts occasionally.

Now back to knowledge about Java multithreading. Recently I published my list of influential books. It did not contain anything about particular technology, but I should add following: Brian Goetz: Java Concurrency in Practice. Everybody programming in Java professionally should know its content by heart. There is no better book about this topic.

I believe it is only fair to downgrade to Junior all Senior Java developers not being able to explain how they use multithreading correctly.

I am currently reading The Art of Agile Development that I've bought at Javapolis last year, but I did not get to it sooner.

I am close to middle of it and I am sure it is the best book I have read about agile development, because it says what, why, how, when not and alternatives (if they exist).

What inspired this post was reading chapter No Bugs. I could not stop thinking about it and I have shown it to all colleagues in my team. It contains something that should cause envy among the most of programmers.

However, XP teams can achieve dramatically lower bug rates. [Van Schooenderwoert]'s team averaged one and a half bugs per month in a very difficult domain. In an independent analysis of a company practicing a variant of XP, QSM Associates reported an average reduction from 2,270 defects to 381 defects [Mah].

and later on

For example, [Van Schooenderwoert] delivered 21 bugs to customers. Working from Capers Jones' data, Van Schooenderwoert says that a "best in class" team building their software would have generated 460 defects, found 95 percent of them, and delivered 23 to their customer. In contrast, Van Schooenderwoert's team generated 51 defects, found 59 percent of them, and delivered 21 to their customer. At 0.22 defects per function point, this result far exceeds Capers Jones' best-in-class expectation of two defects per function point.

It is very hard to imagine something like that even I think projects I've been working for last few years were better than average regarding bug count (I have no data to prove that to you or even me, it is just feeling).