When you copy/shade classes then there is no sealing metadata copied, so unless the code verifies how it is packaged, it will not know that it isn't sealed anymore (or to a different package).
But I guess it doesn't matter, there are many libraries which can be shaded and many which can't, for various reasons. That does not mean it's generally not possible to reduce some dependencies. Gruss -- http://bernd.eckenfels.net ________________________________ Von: Gary Gregory <garydgreg...@gmail.com> Gesendet: Saturday, July 25, 2020 10:22:58 PM An: Commons Developers List <dev@commons.apache.org> Betreff: Re: [all] When to update dependencies? How does this work with sealed jars? Gary On Sat, Jul 25, 2020, 15:57 Bernd Eckenfels <e...@zusammenkunft.net> wrote: > It will only cause problems if this is registered as a service/spi/driver > like XML, Crypto, JDBC, Authentication and so on. For internal libraries > functions which don't have such global state it's fine. > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > ________________________________ > Von: Torsten Curdt <tcu...@vafer.org> > Gesendet: Saturday, July 25, 2020 8:29:21 PM > An: Commons Developers List <dev@commons.apache.org> > Betreff: Re: [all] When to update dependencies? > > > > > They’re not the same class and that’s the problem. It’s similar to > loading > > two versions of the same library in OSGi > > > Let's say you are dealing with > > org.vafer.Foo > > the library relocates this as > > org.apache.commons.compress.internal.org.vafer.Foo > > The library only deals with > > org.apache.commons.compress.internal.org.vafer.Foo > > They cannot get mixed up. > Please explain how this will cause problems. >
