More generally, the benefits of being cross-platform “pure Java” are important to me. The only thought I’ve given to native code is to immediately rule it out.

While I agree with several of your points about obfuscation, it DOES have benefits. I spent some time as a J2ME developer for a local startup, and there was a hard limit on what size JAR file different phones would accept. Proguard was an absolute dream in this scenario, shaving off 30%-40% of the JAR size- it was what let us get our applications onto the phone. A 128KB ceiling is a tricky obstacle, especially when you’re writing games (where graphics can easily take up a third of the overall jar, if not more). We were able to write readable, maintanable code without sacrificing file size.

I agree with some of that, especially no. 1, but think it all has to be taken in context.

My own context is that:
- The product involved will have a zero-cost edition;
- People can decide for themselves whether or not to buy the “licenced” edition for its extra features as they see fit (it’s up to me to make that worthwhile…);
- None of the actual functionality will be obfuscated, only some very specific pieces of the licence-checking code;
- The obfuscation won’t be widespread “renaming”, just internal changes within the byte-code of specific methods to make them slightly non-trivial to decompile/replace;
- As stated in the post, I don’t see this as worth lots of time, effort, or cost, or as somehow foolproof – in keeping with point 1 of your comment I largely trust my likely customers, and just want a minor obstacle to effortless hacking by all and sundry.

More importantly, for anyone that wants the source code so that they can modify it, or to guarantee they can maintain/support it themselves if necessary, or if they want the unobfuscated code for any other reason, this will also be available – there will be a site-licenced edition that comes with full source code including test cases (with 100% code coverage) and Ant build script.

With regard to your general comment, this particular product is a tool to help with testing. There’s no issue of claiming this is some kind of reusable business component that’s somehow better than a company’s own way of doing things, and no issue over “data” security. I think you might have been imagining an entirely different category of product – probably my fault for not spelling this out.

Obviously, your mileage may vary – in many situations obfuscation may be a very bad idea, for the reasons you’ve explained. In other situations it may be entirely reasonable or even absolutely vital.

As for 5.c, anyone that suffers this has problems far more fundamental than obfuscation, and have only themselves to blame (source control? backup? disaster recovery? due diligence?). I don’t think relying on copying the code back from your customers is the answer, with or without obfuscation!

Mike