Blackcap Blog

Published at 20:46 on 28 July 2023

Building on this entry, let us relate a little story that transpired in the past week.

About a week ago, I make a stupid error and introduce a bug into the code. Shouldn’t be a big problem; one good thing about where I work is that there is a very extensive battery of tests for things.

But this is the Java universe we are talking about. Simplicity is not appreciated as a virtue. Both the test and build frameworks are ginormous and hypercomplex. Somehow, I still do not know why, some feature got triggered that caused the test(s) that would have detected my bug to fail to run.

Because the Java universe does not appreciate simplicity, that code base itself is ginormous and hypercomplex. If the code were not written by members of such a dysfunctional programming culture, it would have been broken up into smaller, more managable bits that communicated with each other somehow. The test log for the subset of the code I was working with would have been short enough I would have probably noticed something missing. Instead, the missing tests were buried in a little over 80,000 lines of test and build output. Can you read an 80,000 line log file without falling asleep first? I sure can’t. So I didn’t even try. Naturally, the missed tests go unnoticed.

The check-ins get rejected for other reasons, so I get to work on addressing them. Meanwhile, the whatever-it-was that caused the critical tests to get suppressed ceases to do so. So my first attempt to test the recode fails for this out-of-the-blue, off-the-wall reason. I look at my recent changes and see nothing that could cause this issue to manifest.

Not much can be done but to attempt to instrument the daylights out of the code with debug log statements and try to figure out what the heck is going on with the data as it gets operated on.

My first attempt to do so fails because the company’s network infrastructure suffers a hiccup and causes my build to fail. The company’s infrastructure is super-complex, poorly-documented, and unreliable. (Everyone else just basically accepts it because everyone else is a Java programmer and thus used to unnecessary complexity and the resulting unreliability.)

In my second attempt, I discover that for some reason the test framework suppresses all log messages. So I recode to use writes to standard output, figuring (correctly) that it won’t “intelligently” suppress those. The instrumenting turns out to be insufficient, so I add more.

Each of these iterations takes way, way longer than it should, because the code is big and bloated and complex and so takes 30–45 minutes to build. If everything was factored into smaller units, I doubt builds would take longer than 5 minutes (if that). So each iteration takes roughly 6 to 10 times longer than it should.

Finally, after at least 4 hours of effort, I locate the bug.

And this is why I hate Java. Not because of the core language itself (dated, but still not bad considering it was designed in the ’90s) or because of its runtime (still one of the best virtual machines out there), but because of the traditions of the community that uses it. A minor bug, that would have been resolved in half an hour easily, instead almost makes it into production and takes half a day to resolve.

And this happens everywhere, all the time. Everything is more difficult, more tedious, and more error prone than it should be, with a lot more busy work than there should be.

Those dysfunctional traditions are such an irritant that I have developed my own special term for them: Java community antipatterns, or JCA’s for short.

I have recently learned that I am on my way out where I work, mainly because I can’t cope with the JCA’s as well as the Java careerists. And frankly, I can’t wait till I move on. I’m already looking for another position, and it will be as far from the enterprise Java world as it can be.