LOG kills

Never activates log in DEBUG mode. That kills memory and performance. Always use INFO. Debug should be used with AOP to trace execution only.

Money money money, bug me honey

Money
   int value;
   String currency;

Money add(Money initial, Money toAdd) {
   int value = initial.getValue() + dogAmount.getValue();
   Money money = new AnimalMoney(value, initial.getCurrency())

   return money;
}

Everything looks alright, but it's not.

Try to add money using these one :

   Money cat = new AnimalMoney(5, "cat");
   Money dog = new AnimalMoney(1, "dog");

   Money deal = add(cat, dog);

You will obtain 6 values of cat. Does 5 cats plus 1 dog equals 6 cats. I think not.

Always think about the type of what you deal with. Remember your physics lectures when we calculate the result kind, like multiply hours by km per hour.

One solution can be to lower the accessibility of the inner elements. Money value and currency should not be manipulated outside its package. Outside package code must only use helper function to manipulate them.

OutOfMemoryError Problem To Log

How appears a vicious OutOfMemoryError on 2/3 of the dev computer ?

The same JVM, the same sources, the same web server...

Everything is the same ! Everything ? Not the application config file nor the log4j config file.

Yep, OutOfMemory because of DEBUG level, others with INFO. Why ? Because of the fuck root handler the gives the DEBUG level for every API that use log4j, and so for the one that log the application database access. More than 1GB while we use only 300MB ordinary.

Becareful with logger. Always use root INFO and provides category for your application packages.

To be null or not to be ?

Book myBook = getBookFromSomeWhere();
System.out.println("myBook: " + myBook);

if (myBook == null) {
    System.out.println("myBook is null");
}
else {
    System.out.println("myBook is not null");
}

Run it ! And that display :

myBook: null
myBook is not null

How is it possible ?

Hahaha.

It is because we have:

Book {
...

public String toString() {
    return "null";
}

Funny, isn't it ?

Out of subject : Errare Humanum Est

Basically the implementation look like :

if client => send email to client
if enterprise => send email to client
if others => send email to client

BUT this behavior was not as specified. It should be :

if client => send NO email
if enterprise => send email to enterprise
if others => send email to enterprise

And guess what, it was in production because of ME. Yes, ME. I'm gonna kill myself. How it could be, how I could make such a mistake. By focusing too much on code aspect.

This teach me a great thing. Of course the code aspect, the architecture and so on are important, but the business target IS MORE IMPORTANT than every thing.

Today, I was the stupid guy because Errare Humanum Est.

What time is it ?

// defined previously
// Date aDate = ...

Date date = new Date();
date = new Date(date.getTime());

if (aDate != null && aDate == date) {
    date = new Date(date.getTime() + 10);
}

Hum, the biggest problem with this one is the equality condition test (aDate == date).
In java, == DOESN'T compare value, except for primitive data type, it compares pointer.
That's it, it test if two objects are same. To test if two object are equal (in value) use Object.equals method.


Then, it is trivial that

Date date = new Date();
date = new Date(date.getTime());

is stupid.

Date date = new Date();

is sufficient.

cast it

public static int roundSup(float n){
    int round=0;

    if(n > (new Float(n).intValue()))
    round = new Float(n+1).intValue();
    else round=new Float(n).intValue();

    return round;
}

Sure it needs to create new Float object to do this operation. And the code is ugly.

Try this,

public static int roundSup(
        final float n
) {
    return ((int) n) + 1;
}

Wow ! Cleaner, clearer, better !
Why just a cast will do it ?

See Java Language Specification 3rd : Narrowing Primitive Conversions

But don't forget to COMMENT you're code ! A code without comments it's like a life without meaning.