Proguard shrinkage

I ran proguard on the jme.jar release .7 and it went from about 1.2 MB to 146kb, as well as making it completely unreadable with a decompiler. If you’re releasing a game, I suggest you try it out.



Also really nice for anyone wanting to webstart their applications

Smaller is good. Source code is public so the decompilation of the library is not really an issue. :stuck_out_tongue: But I like smaller!



EDIT: Did you try using this and running tests and the like? I read on their site that it shrinks the jar by removing unused classes and fields… not really a good thing when you are talking about a library jar by itself.

Looks like that’s only possible with an unsigned version of the jar? (Trying to run my game only works if I merge in the unsigned one)

One last comment from me on this. :slight_smile: I tried obfuscating Dirt… It worked (the game starts and I can go through the menus) until it tried to load in a class using forName where the string was dynamic. Is there any way for it to recognize a String matches a class name regardless of where the String is and not obfuscate that?



I think I could get it to work, but I’d have to go through and specify lots of things not to obfuscate. :?

From their FAQ:

Does ProGuard handle Class.forName calls?
Yes. ProGuard automatically handles Class.forName("SomeClass") and SomeClass.class constructs. The referenced classes are preserved in the shrinking phase, and the string arguments are properly replaced in the obfuscation phase.

With variable string arguments, it's generally not possible to determine their possible values. They might be read from a configuration file, for instance. However, ProGuard will note constructs like "(SomeClass)Class.forName(variable).newInstance()". These might be an indication that the class or interface SomeClass and/or its implementations may need to be preserved. The user can adapt his configuration accordingly.


How was your file size?
"Cep21" wrote:
From their FAQ:
Does ProGuard handle Class.forName calls?
Yes. ProGuard automatically handles Class.forName("SomeClass") and SomeClass.class constructs. The referenced classes are preserved in the shrinking phase, and the string arguments are properly replaced in the obfuscation phase.

With variable string arguments, it's generally not possible to determine their possible values. They might be read from a configuration file, for instance. However, ProGuard will note constructs like "(SomeClass)Class.forName(variable).newInstance()". These might be an indication that the class or interface SomeClass and/or its implementations may need to be preserved. The user can adapt his configuration accordingly.

Then it will not work for my editer.