Quibble:

If you're building a library of any complexity, it can be very
difficult to ensure that only the classes and methods you want to be
public (that is, that you intend to support in future version of the
library) are called across package boundaries.  E.g, I build a utility
class and call if from various places in my library, knowing full well
that I haven't really thought its use through and may want to refactor
it later.  I have no real choice but to make it a public class with
public methods.  Users of such libraries have a distressing habit of
finding such classes, figuring out what they do, using them, and then
complaining when upgrading to a later release breaks their
application.  Using an obfuscator to change the class name to
NJvbuuU456 and its methods to jkkKJ66, jJhgf88, and IIUysdgsgG33 is a
handy way of preventing that.

(I'm wondering now: does the JVM enforce the Java rules for class and
method names?  It would be even better for the obfuscated names to
contain spaces, making them uncallable from Java.)

That was exactly my point. Obfuscators (and also copy protection) are
snake oil. Any kind of expensive cryptography or similarly that relies
on security through obscurity (including any that put the decryption
keys on untrusted systems but try to hide them from those systems'
administrators, including in turn every form of copy protection known
to Man) is snake oil and not worth so much as one lousy thin dime or
moment of your time, nevermind whatever's actually being charged for
it.

Obfuscation is, essentially, weak encryption. Copy protection (or
using *real* encryption on the binary and an obfuscated stub that
decrypts it, which is a stronger form of obfuscation) is stronger
encryption but leaves a decryption key in the hands of every would-be
attacker, albeit hidden or obfuscated in some manner. It only takes
one to manage to decrypt and crack your app and upload it to p2p and
warez sites and free copies are out there and easy for anyone else to
download and install, so it doesn't matter if Joe Average can't crack
it; Joe Average *can* use Limewire and someone else *can* both crack
it *and* use Limewire. And sooner or later, someone will, unless your
product is so obscure that your main problem is low volume. In that
case, free copies will, through network effects, actually raise sales
volume anyway, and right when you want it least your copy protection
suddenly is actually effective! Ouch.

Crypto that relies on secrecy of the algorithm is similarly snake oil.
The MPAA found this out to their chagrin when the CSS* copy-protection
emperor was discovered to be devoid of clothing a decade or so ago.
The same mistake keeps being repeated over and over in computing
history though, with the odd prominent case (a vulnerable e-voting
machine here, some ATMs being hacked there...) or high-profile
individual leak of supposedly-secure data and a constant low-grade
churn of instances that go unnoticed. AES, Blowfish, and the
asymmetric ciphers used to encode symmetric session keys for things
like SSL are all you really need (with a big enough key size; stay
away from 56-bit DES, which is dead).

Of course, some entities just don't learn. The MPAA learned a little
after the CSS debacle and relied on stronger crypto with their HD-DVD
AACS encryption. Too bad they forgot that copy protection is
invariably essentially DOA anyway because it puts the keys in the
hands of the untrusted parties. AACS has, predictably, been cracked
wide open, and all their fancy key-revocation nonsense did was make it
need cracking every few months instead of just once. :P

* Check out http://en.wikipedia.org/wiki/Content_Scramble_System --
just the phrase "proprietary 40-bit stream cipher" is sufficient to
give any security expert the willies, and enable him to accurately
guess its current essentially-defunct status at the same time, if it
weren't that any security expert worthy of the title already knows
what CSS is and what happened to it. CSS got pretty much *everything*
wrong, since it a) was copy protection and thus gave potential
attackers the decryption keys, b) had fewer bits than even DES, and c)
had a proprietary algorithm ALL AT THE SAME TIME. :P And millions of
dollars were wasted on this boondoggle, and again on its successor
AACS which made at least the first of the three mistakes all over
again and likewise was rapidly cracked.

Perhaps it won't fully satisfy the OP's desire to protect their code, but  
that doesn't make it useless.

You could make a case that it has merit since it raises the barrier for  
reverse-engineering.  However, ignoring that argument completely (since I  
sense you are taking the position that obfuscation provides no benefit in  
this respect), obfuscators still perform another important function.

An obfuscator will typically reduce the size of the compiled code by 50%  
or more.  This can be useful for applets and Web Start applications (saves  
on data transfer costs and download times) but even more so for mobile  
development.  In fact, for J2ME, the primary reason for using an  
obfuscator is for the shrinking, the IP considerations are secondary.

So yes, I do think there is a point in using an obfuscator for certain  
projects.  Now where do I collect that bridge?

Dan.