> Am 25.05.2017 um 18:23 schrieb Oliver Heger <oliver.he...@oliver-heger.de>: > > > > Am 24.05.2017 um 13:55 schrieb Stephen Colebourne: >> On 23 May 2017 at 17:17, sebb <seb...@gmail.com> wrote: >>>> Yes, the >>>> code compiles and both can be on the classpath, but it is a pain to >>>> use, just a different kind of hell. >>> >>> I don't see what the problem is here. >> >> Library A that depends on lang3 returns a Pair. >> Library B that depends on lang4 takes a Pair. >> Application cannot pass Pair from A to the B without conversion. >> >> My point is that it is possible to over-worry about jar hell. >> Joda-Time removed some methods when it went from v1.x to v2.x, but >> didn't change package name or maven co-ordinates. It was far more >> important that end-users didn't have two different LocalDate classes >> (a problem that couldn't be avoided when moving to Java 8). I've never >> seen any feedback about the incompatibility causing jar hell. >> >> The same is true here. It is vital to think properly about which is >> the worse choice, not just assume that jar hell must always be >> avoided. >> >> I remain completely unconvinced that removing these two problematic >> methods justifies the lang4 package name, forcing end-users to have >> three copies of the library on the classpath. It should need much, >> much more to justify lang4 package name. In fact I've yet to hear >> anything else much in this thread that justifies a major release. > > I also think that a new major release just to fix this problem would be > overkill and cause clients even more trouble. > > Would the following approach work as a compromise: > > - [lang] declares an optional dependency to the desktop module. > - All affected classes (AbstractCircuitBreaker and its two sub classes) > are marked as deprecated. > - Copies are created from the original classes with slightly changed > names or in a new package (tbd). These copies use a new change listener > mechanism. > > IIUC, the resulting [lang] module can now be used without the dependency > to desktop when the new classes are used. The dependency will only be > needed for the deprecated versions.
Let’s do it like this. Sounds like the right way to me. Benedikt > > Oliver > >> >> Stephen >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
