On Mar 20, 2007, at 7:54 , Felix Meschberger wrote:
On 3/19/07, Marcel Offermans <[EMAIL PROTECTED]> wrote:
Something that might be interesting here is to use Bnd together with
one of the code obfuscators. Not to obfuscate anything, but to rip
out all utility code that is not used. That way you can just inline
the stuff you actually use.
That could be a strategy to try with all utility bundles, not just
this one. It might save you a lot of code in big libraries of which
you use only a small portion.
Interesting, indeed. Couldn't this be done by BND ? After all BND has
all the inter-class dependencies to handle this, or am I completely
wrong ?
It could be done by BND, but I would not want Peter to start
implementing his own obfuscator, so it's probably best to choose an
existing obfuscator and feed it the information that BND has
"discovered". I just took a brief look at ProGuard (http://
proguard.sf.net/) and it can be configured to just "strip" code.
Of course this fails blatantly when classes are accessed through
reflection, but this would definitely be a different story...
Good obfuscators can even spot some of the more common reflection use
cases:
- Class.forName(stringConstant) and
- (castthatrevealstheclass)Class.forName(whatever).newInstance()
But in general you are right, you should probably use some caution
when using such a tool.
Another path might be to not link such a step in the packaging
process to BND at all, and just create a separate post-processing
step for it. In that case, you would want to be able to feed ProGuard
the bundle and have it figure out the manifest itself. That does not
sound too hard. :)
Greetings, Marcel
