Do you obfuscate your commercial Java code? [closed]

I wonder if anyone uses commercial/free java obfuscators on his own commercial product. I know only about one project that actually had an obfuscating step in the ant build step for releases.

Do you obfuscate? And if so, why do you obfuscate?

Is it really a way to protect the code or is it just a better feeling for the developers/managers?

edit: Ok, I to be exact about my point: Do you obfuscate to protect your IP (your algorithms, the work you've put into your product)? I won't obfuscate for security reasons, that doesn't feel right. So I'm only talking about protecting your applications code against competitors.

@staffan has a good point:

The reason to stay away from chaining code flow is that some of those changes makes it impossible for the JVM to efficiently optimize the code. In effect it will actually degrade the performance of your application.

If you do obfuscate, stay away from obfuscators that modify the code by changing code flow and/or adding exception blocks and such to make it hard to disassemble it. To make the code unreadable it is usually enough to just change all names of methods, fields and classes.

The reason to stay away from changing code flow is that some of those changes makes it impossible for the JVM to efficiently optimize the code. In effect it will actually degrade the performance of your application.

I think that the old (classical) way of the obfuscation is gradually losing its relevance. Because in most cases a classical obfuscators breaking a stack trace (it is not good for support your clients)

Nowadays the main point to not protect some algorithms, but to protect a sensitive data: API logins/passwords/keys, code which responsible for licensing (piracy still here, especially Western Europe, Russia, Asia, IMHO), advertisement account IDs, etc.

Interesting fact: we have all this sensitive data in Strings. Actually Strings is about 50-80% of logic of our applications. It seems to me that future of obfuscation is "String encryption tools".

But now "String encryption" feature is available only in commercial obfuscators, such as: Allatori, Zelix KlassMaster, Smokescreen, Stringer Java Obfuscation Toolkit, DashO.

N.B. I'm CEO at Licel LLC. Developer of Stringer Java Obfuscator.

I use proguard for JavaME development. It's not only very very good at making jar files smaller (Essential for mobile) but it is useful as a nicer way of doing device-specific code without resorting to IDE-unfriendly preprocessing tools such as antenna.

E.g.

public void doSomething()
{
    /* Generated config class containing static finals: */
    if (Configuration.ISMOTOROLA)
    {
        System.out.println("This is a motorola phone");
    }
    else
    {
        System.out.println("This is not a motorola phone");
    }
}

This gets compiled, obfuscated, and the class file ends up as though you had written:

public void doSomething()
{
    System.out.println("This is a motorola phone");
}

So you can have variants of code to work around manufacturer bugs in JVM/library implementations without bulking out the final executable class files.

I believe that some commercial obfuscators can also merge class files together in certain cases. This is useful because the more classes you have, the larger the size overhead you have in the zip (jar) file.