Re: About jobfuscate
Mark Space wrote:
Joe Attardi wrote:
twerpinator@gmail.com wrote:
If you think that there's any point in doing so, well ... I have
this bridge I've been trying to unload that I'm willing to let go
for the low, low price of $17,569.99 ...
The OP was not asking for your philosophical opinion on code
obfuscation. We all know that closed-source or proprietary software
is the evil work of the devil, but spare this guy the lecture and
just let someone answer his question...
It is nevertheless humorously appropriate in this case. The OP may
be unaware that obfuscation isn't going to provide much benefit.
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.)