On Fri, Jul 24, 2020 at 10:02 AM Torsten Curdt <tcu...@vafer.org> wrote:
> > > > You can imagine all manner of jar-hell created by shading. For instance: > > > - library L1 shades library ShadedA-1.0 and ShadedB-1.1. > > - library L2 shades library ShadedA-1.1 and ShadedB-1.0. > > - An app wants to use L1, L2, ShadedA-1.1, and ShadedB-1.1 but it can't > no > > matter what classpath ordering it uses. > > - An app wants to use L1, L2, ShadedA-1.0, and ShadedB-1.0 but it can't > no > > matter what classpath ordering it uses. > > > > Sorry, but I cannot follow the problems you are trying to show. > > L1 has ShadeA and ShadeB > L2 has ShadeA and ShadeB > but both have their own version that doesn't clash and that doesn't know > anything about the other one. > The app does not see ShadeA or ShadeB from L1 or L2 (unless it uses the > hidden package from L1 which would be stupid) > There are no clashes and every library uses the version that it needs. > The key phrase is "which would be stupid" which you as a consumer have zero control over. People do stupid things all the time. > To be more explicit. I am maintaining org.vafer.jdependency which uses > org.objectweb.asm. > If you look at the final jar you find > > org/vafer/jdeb/shaded/objectweb/asm/*.class > > The shaded classes are relocated and become part of the context of the > library that is shading. > A shading hell is just not possible as long as there are no classpath > problems on the library itself. > And this contributes to the problem: This library has now made it impossible to pick up a fix in ASM or just plain support for a new Java version. Gary > It's like you are copy&pasting the code into your package. > Bytecode manipulation is really not that bad as you make it to be. > > Just creating uberjars (without relocation) - that's a whole different > story. > That should only ever been done on the final application artifact. >
