Eclipse Package Explorer: Hide part of long package names

Really nice tip on eclipse. 
Eclipse Package Explorer: Hide part of long package names?

when logger crashed the application

Ever heard a logging statement causing out of memory crashes in an application.

Some technical details: (Though most of the folks stopping by should already know, but I talked to few techi folks who weren't aware about it)

When you write

logger.debug("got a request to execute"); // We are good.

But when you write

logger.debug(heavyObject.toString());       // or
logger.debug("some string" + "some string" + someHeavyObject);

your application (and common sense) goes down the hill. 

One will argue that heavy operation will happen only if log level is debug. 

But that's wrong. Because, even before the flow reaches inside 'logger.debug', the object transformation is done. No, this is not because your logging library is bad, but because that's how Java is, and even most of the other languages. That's the way its suppose to be.

So please guard the heavy logging statements with log level check.

if (logger.level==debug) {
       logSomeHeavyStuff();
}

Yes that's ugly but that will save your application some precious CPU and memory.

Recently the project I was working on, was getting OutOfMemory crashes. That's what happen when you try to convert a 60,000 object array into a string for a trace level debugging. :)

Why that object grew to 60K, is another story to be told some other day. 

Blaming the wrong guy

I remember a Dilbert strip regarding pointy hair boss solving a wrong problem.

Saw this the other day - https://tedvinke.wordpress.com/2014/02/13/mockito-why-you-should-not-use-injectmocks-annotation-to-autowire-fields/

Though the problem regarding not using constructor is right, as it ends up giving a partially created class object in the test, but putting the blame on InjectMocks is totally wrong.

Injectmocks does what it suppose to do, if the developer is not following good programming practices, and is not aware which dependencies will get used in the unit test flow, then you cant blame the framework.

Just to go bit off topic, I had problem with InjectMocks, even after providing all the autowired beans, it jumbled them up. Reason - There were couple of prototype beans and I was injecting the Provider interface in the constructor. Here mockito was getting confused in mapping the correct providers . There I was forced to use the manual initialising of SUT using constructor. Not sure if the problem exists in the newer versions also.