commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <mben...@apache.org>
Subject Re: [LANG] Thoughts about Lang 4.0
Date Wed, 24 May 2017 12:43:14 GMT
On May 24, 2017 6:56 AM, "Stephen Colebourne" <scolebourne@joda.org> wrote:

On 23 May 2017 at 17:17, sebb <sebbaz@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 hear your argument, and I want to be open minded, but I can't get past
the feeling that [lang] is (or should be ;) ) such a ubiquitous, low-level
dependency that to break BC in almost any manner, however seemingly
trivial, is to invite havoc for downstream users at unpredictable distances.

Matt


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.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message