I am that interested in making an obfuscator but shrinking the bundle
could be an interesting function. I already have all the information
anyway. Obviously I can only throw away private packages, with OSGi
you never know who will use the exported packages.
I actually think that this will be a problem with a generic tool,
throwing away exported packages.
Kind regards,
Peter Kriens
MO> 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 ?
MO> It could be done by BND, but I would not want Peter to start
MO> implementing his own obfuscator, so it's probably best to choose an
MO> existing obfuscator and feed it the information that BND has
MO> "discovered". I just took a brief look at ProGuard (http://
MO> 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...
MO> Good obfuscators can even spot some of the more common reflection use
MO> cases:
MO> - Class.forName(stringConstant) and
MO> - (castthatrevealstheclass)Class.forName(whatever).newInstance()
MO> But in general you are right, you should probably use some caution
MO> when using such a tool.
MO> Another path might be to not link such a step in the packaging
MO> process to BND at all, and just create a separate post-processing
MO> step for it. In that case, you would want to be able to feed ProGuard
MO> the bundle and have it figure out the manifest itself. That does not
MO> sound too hard. :)
MO> Greetings, Marcel
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
