Chicken or Egg

These days it is practically hard do not use a Spring. I suspect the explosive blooming of JVM languages nowadays may be just a desperate attempt to escape this beast, gradually acquiring the Java world. And despite I'm not especially thrilled about it, my last three contracts were around so, I might admit this. Last its reincarnation on the market, the Spring Boot, looks solid on glance. The dependency hell of its previous incarnation was polished by Maven's BOM. I barely can see areas it doesn't cover, it looks like a pretty mature framework that seems self-sufficient and, no doubts, it is a pretty handy tool for practically any Web related PoC. Swiss knife in middleware, give or take. Design microservices from scratch or moving an old monolith towards to, most likely brings the Spring Cloud into consideration. Plenty workforce resources on a market are familiar with it thus gives it advantage over alternatives. Plus it requires only declarative configuration with minimal or even none of code: so, less code, less bugs.

Big-Oh: Constant vs Logarithmic

- Do you know what is quickest ever method to lookup string?

- Mmmm. Apparently hash table.

- Nope. Dude, its well known that binary search is quicker!

- ?!

Kind of similar to that was a conversation with one guy. (Cheers, Noel!) No doubt, to put it mildly, it sounds crazy: method with logarithmic asymptotic complexity outperform constant one. But it is only on first look. The devil is hiding in details, as always...

Part 1a. "Какая гадость... Какая гадость эта ваша заливная рыба"

These days, there are more tools to play with benchmarks. No doubts, its really hard to do especially if they are micro. Let's cheers up an JMH. Really pretty good and easy to use framework for a writing the micro benchmarks for a JVM. To play with, I decided to come back to my old investigation about the Spring proxying, I did some time ago. But now, the list of targets are extended and tests are more representative.

Gradle, Groovy and other...

That probably will be a shortest post in this blog. Shortest coz I do not think that this subject deserve more. I should admit, more and more noise I can hear around this. I would say an any thread about a build system eventually diluted by Gradle. And you know what I think about this?

Part 2. "Какая гадость... Какая гадость эта ваша заливная рыба"

- You should avoid the assertion and use an IllegalArgumentException.
- Why?
- Coz assertion will be disabled in production. It changes behaviour of your application and may lead to confuse.
- (?!)

Actually reasoning could be different, from "misuse of feature" coz "it generates java.lang.AssertionError that indicates significant error, like java.lang.OutOfMemoryError" up to "it put application on unpredictable state". I was pointed out to google such matter. And I actually did this, after all...

I won't dive into the jungle of distorted perception of the world. So many people, so many opinions. I don't care, really. That is depend on how bad experience had been in past. What actually I should admit, if experience was overdosed by Spring, the reasoning could jump a really unexpected direction. That actually may not surprise, if you never saw your application in profiler, just a Spring configuration… How you may know what really your application are doing, right?

So often in past, hunting the idea what the heck burning the Joules on a CPU, I can see the ridiculous situation when simple action followed by tremendous effort in attempt to do so. Just from top of my head, an update the element of array of rates of the currency pair with an incoming price may go through dozen of checks that this price is not null (or symbol it related to). Yes, dozen times! Damned org.springframework.util.Assert.* calls were everywhere. Just because application was written by many developers and each one decided to check input parameter(s) on each method entrance, on each f..n layer. I pretty sure that happen not only to me. Just have a look at the stack trace of your code, you may found similar cases on some of an execution paths. Especially if you uses Spring.

Yeah, it could be the my fault. Just a case of cognitive dissonance, but last time the insidious thought creeps my mind: continuous using of Spring may hurt. Let's have a look why the old fashion JDK assertions may be very attractive and I would encourage people to use them more broadly.

QuickFIX buns

Writing applications with QuickFIX has some fun. The FIX engine there is a classical IoC, event driven. Application that uses it has to have only business specific things don't bother with tedious FIX noodles. Easy peeasy.

However, sometimes I have had anxiety because that specifics were not covered properly by tests. No, I tried, tried hard really. With mock or without it, tests for application with QuickFIX looks ugly and non readable due its restrictive and cumbersome design. Very often I had to remove them or simplify their verification because clearly understood that after couple months even I will not be able support it.

Eventually I came to an idea to simplify all that. QuickFIX users may appreciate this. :)

Objects in mirror are closer then they appear

First time I heard this phrase from the Thomas Jahn’s "Knockin’ on Heaven’s Door". In Russian it would sound like "reflected objects are closer than appeared". But that doesn't deform the sense, isn't? Exactly, namely distortion. That what appeared to be when I benchmarked the hash code calculation.

Part 1. "Какая гадость... Какая гадость эта ваша заливная рыба"

In past I spent some times on optimization of performance mostly JSE application. Recently I had a chance to play with enterprise Java.

Yes, they both are pretty same Java and life does not become heavier when you moving from Standard Edition land to Enterprise one. Except one note: the enterprise app supposed to be more complex so, is more "layered" application. Kind of "Shrek's onions":

- Ogres are like onions.
- They stink?
- Yes. No.
- Oh, they make you cry.
- No.
- Oh, you leave em out in the sun, they get all brown, start sproutin' little white hairs.
- No! Layers! Onions have layers. Ogres have layers. Onions have layers. You get it? We both have layers!
- Oh, you both have layers. Oh. You know, not everybody like onions.

Thats true, not everybody like ... layers. Especially when we talk about high performance, low-latency applications. Some people implied the Java to a heavy, multi-layered applications and blames it for so slow speed in comparison with C/C++. But, I think, that is unfairly...

"".equals(val.trim()) vs. 0 == val.trim().length()

Trimming string values a quite often task on the Web. I personally prefer avoid this in origin: just do not store redundant symbols. But you know, shit is happened... Sometimes data you have to use, came from side you can not control. Or even trimming is assumed by protocol.

String transformations are heavy by nature, but it is not a problem if operation is not time sensitive.

Not sure where and when I picked this habit, but usually I used construction:

if (null == value || "".equals(value.trim())) {
    // data is empty or blank
}

But recently I had been informed that this check is much slower compare to:

if (null == value || 0 == value.trim().length()) {
    // data is empty or blank
}

From my look point they both are heavy and should not be used in code that pretends to be a quick. It is even funny to hear about performance tricks in cases where it never appear to be meaningful. But I become interested how much it slower in fact. So, decided to make a quick test.

Perversion Of Control

Once I had a chance to observe the quite funny picture: the young man fights with baggy pants without belt. Looking on his tremendous efforts to get the equilibrium when pants are still on him but sagging as low as it is possible, I tried to understand why he does this. It looks strange, isn’t it? If to do this for hour by hour, day by days, life may become difficult. What reason to do this? The reason (thanx my wife) was that it is very fashionable thing now. Fashion! People implies fashion often to explain an irrationality.