commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <>
Subject [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
Date Mon, 05 Jun 2017 10:49:23 GMT

> Am 25.05.2017 um 18:23 schrieb Oliver Heger <>:
> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>> On 23 May 2017 at 17:17, sebb <> 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.


> Oliver
>> Stephen
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message