This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Obfuscation - optimisation?
- From: Doctor Bill <docbill at gmail dot com>
- To: java at gcc dot gnu dot org
- Date: Tue, 7 Dec 2004 13:03:55 -0500
- Subject: Re: Obfuscation - optimisation?
- References: <co1hd1$52j$1@sea.gmane.org> <200411241049.15228.konqueror@gmx.de> <41A44C22.8030505@egholm-nielsen.dk> <16804.31174.893199.848014@cuddles.cambridge.redhat.com> <41A47F27.2080201@egholm-nielsen.dk> <16804.33116.532088.535302@cuddles.cambridge.redhat.com> <41A489BA.8080400@egholm-nielsen.dk> <16804.37765.414410.975709@cuddles.cambridge.redhat.com> <41A49BAF.8030904@egholm-nielsen.dk> <41682F20.9080900@web.de>
- Reply-to: Doctor Bill <docbill at gmail dot com>
> But proguard does things like removing unsused stuff VERY efficient or
> making methods that are never orverridden final. removes code withought
> side-effects....
Actually, I've found very sever side effects from pro-guards. It
seems any dynamically loaded class will be completely removed. This
can be manually overridden, but then the methods the dynamic classes
call will still be removed if no other classes call the same methods.
In the end no matter how much I specified to keep, there was always
something else missing that I could only detect by runtime errors. I
expect any code which explicitly Class methods, or java reflection
would have runtime errors.
Byte optimizations are a little better, but seem buggy. I could not
get code using the byte optimizations to run because methods were
rewritten to expect a int return instead of a void return causing
runtime stack errors, even with Sun's JRE.
The only part of proguard's optimization I could get to work without
runtime errors was obfuscation.
Bill