> > Unless I'm mistaken, there is one drawback to shading: Since > it creates new classes, there will be less shared code, hence > one could imagine a potential hit on performance (?). >
Of course it means some code duplication in the final artifact. This means slightly bigger artifacts - but disk space is cheap. In the worst case scenario it means some more memory gets used. For the libraries I am looking at this is insignificant. Same should be the case for performance. But you never know for your use case until you measure it. I see merely a single drawback - and that's when reflection is in the picture. IIRC my original minijar code did work around this for static references, but for dynamic references you were on your own. I think the current incarnation of the shade plugin does not support reflection magic. And maybe it's OK to keep it simpler. I must be missing something: Since shaded classes are supposed > to be "internal", if there is an impact on the public API, the only sane > solution is a bug-fix release that shades the fixed version of the internal > library. No? > That's exactly how it works.
