[LANG] Thoughts about Lang 4.0

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Gilles Sadowski
On Tue, 23 May 2017 15:33:39 +0200, Jochen Wiedmann wrote:
> On Tue, May 23, 2017 at 12:19 PM, Gilles
> <[hidden email]> wrote:
>
>> Can you be explicit with what counts as "noise"?
>
> Lets start with the number of threads, shall we? Or the number of
> "What  depends on what" discussions? Or questions like "Which belongs
> to what?" (Feel free to suggest another measure.)

Everytime someone[1] complained about that, he got the same
answer: it's easy to filter out unwanted threads.

Aren't discussions supposed to happen here?

"Noise" seems relative; from my POV, the flood of automatic posts
(from git, GitHub, Jenkins, JIRA, Nexus) is much more annoying.

Regards,
Gilles

[1] Me too.

>
> Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

sebb-2-2
In reply to this post by jodastephen
On 23 May 2017 at 12:18, Stephen Colebourne <[hidden email]> wrote:

> On 23 May 2017 at 11:54, sebb <[hidden email]> wrote:
>>> Fixing it properly requires a major release, which implies that Lang
>>> 4.0 is still Java 1.7 and should use the `org.apache.commons.lang3`
>>> package name.
>>
>> I think that depends on whether the API is backwards-compatible or not.
>>
>> If it *is* backwards-compatible, then do we need a major release?
>>
>> If *not*, then 4.0 needs a new package.
>>
>> Why?
>>
>> Suppose code A depends on a LANG 3 method not present in 4
>> and code B depends on some new feature in LANG 4
>>
>> It's not possible to use A and B together on the same classpath.
>>
>> In which case 4.0 must use a new package and Maven coordinates.
>
> The change to remove PropertyChangeListener will be incompatible.
> Thus, if you want to be strict then you have to have a new package and
> maven co-ordinates. But IMO, this would simply cause end-user projects
> to have v2.x, v3.x and v4.x on the classpath - its bad enough with two
> versions right now, I don't personally think removing these two
> methods is enough to justify a new package/maven co-ordinate and the
> downstream mess that ensues.

Huh?

The whole point of changing the package name and Maven coords is to
allow mutually incompatible jars to coexist peacefully on a single
classpath.


> I will note that the JDK is removing methods due to exactly the same
> issue - modular Java is quite disruptive..

All the more reason not to cause additional unnecessary problems.

> Options that leave the methods in:
>
> 1) Add module-info for v3.x that "requires java.desktop" and accept
> that end-users get Swing/AWT

OK

> 2) Add module-info for v3.x that "requires static java.desktop" (an
> optional dependency) and accept that users of circuit breaker must
> manually "require java.desktop".

OK

> Options that remove the methods:
>
> 3) Make a backwards incompatible change to remove the bad methods in
> v3.7 (no package name change)

-1

This is a recipe for jar hell.

> 4) Make a backwards incompatible change to remove the bad methods in
> v4.0 (no package name change)

-1

This is a recipe for jar hell.

>
> 5) Make a backwards incompatible change to remove the bad methods in
> v4.0 (with package name change)

OK

> If you do #4 or #5, you also need #1 or #2 for the v3.x branch. #3 is
> aggressive but gets rid of the issue in the fastest way.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Matt Sicker
Tying versions of commons-lang to releases of Java itself makes a bit of
sense to me, but then I do foresee projects containing like 5 different
versions of commons-lang in the future which is somewhat annoying.

On 23 May 2017 at 10:07, sebb <[hidden email]> wrote:

> On 23 May 2017 at 12:18, Stephen Colebourne <[hidden email]> wrote:
> > On 23 May 2017 at 11:54, sebb <[hidden email]> wrote:
> >>> Fixing it properly requires a major release, which implies that Lang
> >>> 4.0 is still Java 1.7 and should use the `org.apache.commons.lang3`
> >>> package name.
> >>
> >> I think that depends on whether the API is backwards-compatible or not.
> >>
> >> If it *is* backwards-compatible, then do we need a major release?
> >>
> >> If *not*, then 4.0 needs a new package.
> >>
> >> Why?
> >>
> >> Suppose code A depends on a LANG 3 method not present in 4
> >> and code B depends on some new feature in LANG 4
> >>
> >> It's not possible to use A and B together on the same classpath.
> >>
> >> In which case 4.0 must use a new package and Maven coordinates.
> >
> > The change to remove PropertyChangeListener will be incompatible.
> > Thus, if you want to be strict then you have to have a new package and
> > maven co-ordinates. But IMO, this would simply cause end-user projects
> > to have v2.x, v3.x and v4.x on the classpath - its bad enough with two
> > versions right now, I don't personally think removing these two
> > methods is enough to justify a new package/maven co-ordinate and the
> > downstream mess that ensues.
>
> Huh?
>
> The whole point of changing the package name and Maven coords is to
> allow mutually incompatible jars to coexist peacefully on a single
> classpath.
>
>
> > I will note that the JDK is removing methods due to exactly the same
> > issue - modular Java is quite disruptive..
>
> All the more reason not to cause additional unnecessary problems.
>
> > Options that leave the methods in:
> >
> > 1) Add module-info for v3.x that "requires java.desktop" and accept
> > that end-users get Swing/AWT
>
> OK
>
> > 2) Add module-info for v3.x that "requires static java.desktop" (an
> > optional dependency) and accept that users of circuit breaker must
> > manually "require java.desktop".
>
> OK
>
> > Options that remove the methods:
> >
> > 3) Make a backwards incompatible change to remove the bad methods in
> > v3.7 (no package name change)
>
> -1
>
> This is a recipe for jar hell.
>
> > 4) Make a backwards incompatible change to remove the bad methods in
> > v4.0 (no package name change)
>
> -1
>
> This is a recipe for jar hell.
>
> >
> > 5) Make a backwards incompatible change to remove the bad methods in
> > v4.0 (with package name change)
>
> OK
>
> > If you do #4 or #5, you also need #1 or #2 for the v3.x branch. #3 is
> > aggressive but gets rid of the issue in the fastest way.
> >
> > Stephen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

sebb-2-2
On 23 May 2017 at 16:22, Matt Sicker <[hidden email]> wrote:
> Tying versions of commons-lang to releases of Java itself makes a bit of
> sense to me, but then I do foresee projects containing like 5 different
> versions of commons-lang in the future which is somewhat annoying.

If the version of Lang is tied to Java, then surely there can only be
one version used at a time?

> On 23 May 2017 at 10:07, sebb <[hidden email]> wrote:
>
>> On 23 May 2017 at 12:18, Stephen Colebourne <[hidden email]> wrote:
>> > On 23 May 2017 at 11:54, sebb <[hidden email]> wrote:
>> >>> Fixing it properly requires a major release, which implies that Lang
>> >>> 4.0 is still Java 1.7 and should use the `org.apache.commons.lang3`
>> >>> package name.
>> >>
>> >> I think that depends on whether the API is backwards-compatible or not.
>> >>
>> >> If it *is* backwards-compatible, then do we need a major release?
>> >>
>> >> If *not*, then 4.0 needs a new package.
>> >>
>> >> Why?
>> >>
>> >> Suppose code A depends on a LANG 3 method not present in 4
>> >> and code B depends on some new feature in LANG 4
>> >>
>> >> It's not possible to use A and B together on the same classpath.
>> >>
>> >> In which case 4.0 must use a new package and Maven coordinates.
>> >
>> > The change to remove PropertyChangeListener will be incompatible.
>> > Thus, if you want to be strict then you have to have a new package and
>> > maven co-ordinates. But IMO, this would simply cause end-user projects
>> > to have v2.x, v3.x and v4.x on the classpath - its bad enough with two
>> > versions right now, I don't personally think removing these two
>> > methods is enough to justify a new package/maven co-ordinate and the
>> > downstream mess that ensues.
>>
>> Huh?
>>
>> The whole point of changing the package name and Maven coords is to
>> allow mutually incompatible jars to coexist peacefully on a single
>> classpath.
>>
>>
>> > I will note that the JDK is removing methods due to exactly the same
>> > issue - modular Java is quite disruptive..
>>
>> All the more reason not to cause additional unnecessary problems.
>>
>> > Options that leave the methods in:
>> >
>> > 1) Add module-info for v3.x that "requires java.desktop" and accept
>> > that end-users get Swing/AWT
>>
>> OK
>>
>> > 2) Add module-info for v3.x that "requires static java.desktop" (an
>> > optional dependency) and accept that users of circuit breaker must
>> > manually "require java.desktop".
>>
>> OK
>>
>> > Options that remove the methods:
>> >
>> > 3) Make a backwards incompatible change to remove the bad methods in
>> > v3.7 (no package name change)
>>
>> -1
>>
>> This is a recipe for jar hell.
>>
>> > 4) Make a backwards incompatible change to remove the bad methods in
>> > v4.0 (no package name change)
>>
>> -1
>>
>> This is a recipe for jar hell.
>>
>> >
>> > 5) Make a backwards incompatible change to remove the bad methods in
>> > v4.0 (with package name change)
>>
>> OK
>>
>> > If you do #4 or #5, you also need #1 or #2 for the v3.x branch. #3 is
>> > aggressive but gets rid of the issue in the fastest way.
>> >
>> > Stephen
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> --
> Matt Sicker <[hidden email]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

jodastephen
In reply to this post by sebb-2-2
On 23 May 2017 at 16:07, sebb <[hidden email]> wrote:
> Huh?
>
> The whole point of changing the package name and Maven coords is to
> allow mutually incompatible jars to coexist peacefully on a single
> classpath.

All you are doing in replacing one kind of jar hell with another.

Removing these methods means that a project that wants to use them has
to use the older version. But if another dependency needs a later
version you have hell.

However, if one dependency uses lang3 Pair and another uses lang4
Pair, you can't make the API call without a messy conversion. Yes, the
code compiles and both can be on the classpath, but it is a pain to
use, just a different kind of hell.

What I'm saying is that I'm unconvinced any use of the lang4 package
is a particularly good idea. Having 2 versions of lang out there has
avoided some problems but created others. Add lang4 package IMO
creates as many issues as it solves.

Anyway, its not really my choice. If the [lang] maintainers want
absolute backwards compatibility, so be it. I can prepare a
module-info based on an optional dependency.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

sebb-2-2
On 23 May 2017 at 16:42, Stephen Colebourne <[hidden email]> wrote:
> On 23 May 2017 at 16:07, sebb <[hidden email]> wrote:
>> Huh?
>>
>> The whole point of changing the package name and Maven coords is to
>> allow mutually incompatible jars to coexist peacefully on a single
>> classpath.
>
> All you are doing in replacing one kind of jar hell with another.

What I mean by jar hell is that it's not possible to have the correct
combination of jars on the classpath.

AFAICT what you call jar hell is multiple independent versions of Lang
on the same classpath.
Not the same at all.

> Removing these methods means that a project that wants to use them has
> to use the older version. But if another dependency needs a later
> version you have hell.

Exactly.

> However, if one dependency uses lang3 Pair and another uses lang4
> Pair, you can't make the API call without a messy conversion.

I'm not sure what you mean here.
Each dependency uses its own Pair.
What API call are you referring to?

> 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.

> What I'm saying is that I'm unconvinced any use of the lang4 package
> is a particularly good idea. Having 2 versions of lang out there has
> avoided some problems but created others. Add lang4 package IMO
> creates as many issues as it solves.
>
> Anyway, its not really my choice. If the [lang] maintainers want
> absolute backwards compatibility, so be it. I can prepare a
> module-info based on an optional dependency.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Benedikt Ritter-4
Why does every discussion at commons become a discussion about jar hell?

> Am 23.05.2017 um 12:17 schrieb sebb <[hidden email]>:
>
> On 23 May 2017 at 16:42, Stephen Colebourne <[hidden email] <mailto:[hidden email]>> wrote:
>> On 23 May 2017 at 16:07, sebb <[hidden email] <mailto:[hidden email]>> wrote:
>>> Huh?
>>>
>>> The whole point of changing the package name and Maven coords is to
>>> allow mutually incompatible jars to coexist peacefully on a single
>>> classpath.
>>
>> All you are doing in replacing one kind of jar hell with another.
>
> What I mean by jar hell is that it's not possible to have the correct
> combination of jars on the classpath.
>
> AFAICT what you call jar hell is multiple independent versions of Lang
> on the same classpath.
> Not the same at all.
>
>> Removing these methods means that a project that wants to use them has
>> to use the older version. But if another dependency needs a later
>> version you have hell.
>
> Exactly.
>
>> However, if one dependency uses lang3 Pair and another uses lang4
>> Pair, you can't make the API call without a messy conversion.
>
> I'm not sure what you mean here.
> Each dependency uses its own Pair.
> What API call are you referring to?
>
>> 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.
>
>> What I'm saying is that I'm unconvinced any use of the lang4 package
>> is a particularly good idea. Having 2 versions of lang out there has
>> avoided some problems but created others. Add lang4 package IMO
>> creates as many issues as it solves.
>>
>> Anyway, its not really my choice. If the [lang] maintainers want
>> absolute backwards compatibility, so be it. I can prepare a
>> module-info based on an optional dependency.
>>
>> Stephen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] <mailto:[hidden email]>
> For additional commands, e-mail: [hidden email] <mailto:[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Jörg Schaible-5
Benedikt Ritter wrote:

> Why does every discussion at commons become a discussion about jar hell?

Because it is so damn easy to create one? ;-)

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

jodastephen
In reply to this post by sebb-2-2
On 23 May 2017 at 17:17, sebb <[hidden email]> 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.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Matt Benson-3
On May 24, 2017 6:56 AM, "Stephen Colebourne" <[hidden email]> wrote:

On 23 May 2017 at 17:17, sebb <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Emmanuel Bourg-3
In reply to this post by jodastephen
Le 24/05/2017 à 13:55, Stephen Colebourne a écrit :

> 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.

That's a valid point, but the severity depends on the library. joda-time
with its date related types is more data centric than lang and its
static utility classes. The risk of incompatible data structures is
lower with lang, but the risk of an unsolvable binary incompatibility is
higher due to its ubiquity. The strategy adopted to mitigate the
compatibility issues really depends on the usage of the library.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Dave Brosius-2
Let's be honest, a Pair class is a bad paradigm, invented for lazyness
which throws away any informative metadata. I'm not sure all of this
fighting is worth it over a this.


On 05/24/2017 09:08 AM, Emmanuel Bourg wrote:

> Le 24/05/2017 à 13:55, Stephen Colebourne a écrit :
>
>> 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.
> That's a valid point, but the severity depends on the library. joda-time
> with its date related types is more data centric than lang and its
> static utility classes. The risk of incompatible data structures is
> lower with lang, but the risk of an unsolvable binary incompatibility is
> higher due to its ubiquity. The strategy adopted to mitigate the
> compatibility issues really depends on the usage of the library.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Rob Tompkins

> On May 24, 2017, at 10:33 AM, Dave Brosius <[hidden email]> wrote:
>
> Let's be honest, a Pair class is a bad paradigm, invented for lazyness which throws away any informative metadata. I'm not sure all of this fighting is worth it over a this.

Dependency/classpath discussions aside (clearly using “Pair” as an example for the sake of discussion), I agree with Dave here on the strangeness of the concept of a Pair or Tuple:

It seems that what we’re taking about is an arbitrarily large, yet finite, collection of one type, and there a substantial number of different ways to represent this.

-Rob

>
>
> On 05/24/2017 09:08 AM, Emmanuel Bourg wrote:
>> Le 24/05/2017 à 13:55, Stephen Colebourne a écrit :
>>
>>> 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.
>> That's a valid point, but the severity depends on the library. joda-time
>> with its date related types is more data centric than lang and its
>> static utility classes. The risk of incompatible data structures is
>> lower with lang, but the risk of an unsolvable binary incompatibility is
>> higher due to its ubiquity. The strategy adopted to mitigate the
>> compatibility issues really depends on the usage of the library.
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Matt Benson-3
On May 24, 2017 9:42 AM, "Rob Tompkins" <[hidden email]> wrote:


> On May 24, 2017, at 10:33 AM, Dave Brosius <[hidden email]> wrote:
>
> Let's be honest, a Pair class is a bad paradigm, invented for lazyness
which throws away any informative metadata. I'm not sure all of this
fighting is worth it over a this.

Dependency/classpath discussions aside (clearly using “Pair” as an example
for the sake of discussion), I agree with Dave here on the strangeness of
the concept of a Pair or Tuple:

It seems that what we’re taking about is an arbitrarily large, yet finite,
collection of one type, and there a substantial number of different ways to
represent this.


Just for the sake of completeness and correctness, the Pair class has
separate type parameters for each item. As to the charge that it is lazy:
sure, but by the same token, so could BiFunction or BiPredicate be
considered lazy, yet they exist in the JDK. Sometimes you just want to get
it done without over-modeling everything, especially if they're used for
implementation rather than as a public API.

Which brings up a fair point: generally speaking it's probably not a good
idea for an API to be defined in terms of some other API, but if a consumer
of [lang] chooses to do that, then they have to deal with the consequences
of compatibility.

Matt


-Rob

>
>
> On 05/24/2017 09:08 AM, Emmanuel Bourg wrote:
>> Le 24/05/2017 à 13:55, Stephen Colebourne a écrit :
>>
>>> 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.
>> That's a valid point, but the severity depends on the library. joda-time
>> with its date related types is more data centric than lang and its
>> static utility classes. The risk of incompatible data structures is
>> lower with lang, but the risk of an unsolvable binary incompatibility is
>> higher due to its ubiquity. The strategy adopted to mitigate the
>> compatibility issues really depends on the usage of the library.
>>
>> Emmanuel Bourg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Dave Brosius-2
Your point about BiFunction and BiPredicate is of course valid, but
there are a couple of things about those things that remediate their
awfulness.


1) They are interfaces, and thus describe function, not storage.

2) They are almost always transiently used, as anonymous/lamda classes,
and so the scope of their use is small.


On the other hand, Pair is a storage mechanism, and so it is quite
likely that you encourage developers to build things like Map<String,
Pair<String, String>> or such, that live long times and have large
scopes. That is heinous.


Anyhow, i suppose it's really a tangential topic to this thread, so i
suppose i hijacked it somewhat, and so apologies... carry on.



On 05/24/2017 11:49 AM, Matt Benson wrote:

> On May 24, 2017 9:42 AM, "Rob Tompkins" <[hidden email]> wrote:
>
>
>> On May 24, 2017, at 10:33 AM, Dave Brosius <[hidden email]> wrote:
>>
>> Let's be honest, a Pair class is a bad paradigm, invented for lazyness
> which throws away any informative metadata. I'm not sure all of this
> fighting is worth it over a this.
>
> Dependency/classpath discussions aside (clearly using “Pair” as an example
> for the sake of discussion), I agree with Dave here on the strangeness of
> the concept of a Pair or Tuple:
>
> It seems that what we’re taking about is an arbitrarily large, yet finite,
> collection of one type, and there a substantial number of different ways to
> represent this.
>
>
> Just for the sake of completeness and correctness, the Pair class has
> separate type parameters for each item. As to the charge that it is lazy:
> sure, but by the same token, so could BiFunction or BiPredicate be
> considered lazy, yet they exist in the JDK. Sometimes you just want to get
> it done without over-modeling everything, especially if they're used for
> implementation rather than as a public API.
>
> Which brings up a fair point: generally speaking it's probably not a good
> idea for an API to be defined in terms of some other API, but if a consumer
> of [lang] chooses to do that, then they have to deal with the consequences
> of compatibility.
>
> Matt
>
>
> -Rob
>
>>
>> On 05/24/2017 09:08 AM, Emmanuel Bourg wrote:
>>> Le 24/05/2017 à 13:55, Stephen Colebourne a écrit :
>>>
>>>> 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.
>>> That's a valid point, but the severity depends on the library. joda-time
>>> with its date related types is more data centric than lang and its
>>> static utility classes. The risk of incompatible data structures is
>>> lower with lang, but the risk of an unsolvable binary incompatibility is
>>> higher due to its ubiquity. The strategy adopted to mitigate the
>>> compatibility issues really depends on the usage of the library.
>>>
>>> Emmanuel Bourg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

Oliver Heger-3
In reply to this post by jodastephen


Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:

> On 23 May 2017 at 17:17, sebb <[hidden email]> 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.

Oliver

>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

jodastephen
On 25 May 2017 at 17:23, Oliver Heger <[hidden email]> wrote:

> 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.

This seems like a reasonable compromise approach to me. Especially as
I haven't heard anything else that would drive the need for a v4.0.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Thoughts about Lang 4.0

garydgregory
On Thu, May 25, 2017 at 9:41 AM, Stephen Colebourne <[hidden email]>
wrote:

> On 25 May 2017 at 17:23, Oliver Heger <[hidden email]>
> wrote:
> > 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.
>
> This seems like a reasonable compromise approach to me. Especially as
> I haven't heard anything else that would drive the need for a v4.0.
>

We have started to move code from [lang] to [text]. Once we are happy with
[text], we can deprecate the code in [lang] and that would be another item
for lang4.

Gary

>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Reply | Threaded
Open this post in threaded view
|

[LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

Benedikt Ritter-4
In reply to this post by Oliver Heger-3

> Am 25.05.2017 um 18:23 schrieb Oliver Heger <[hidden email]>:
>
>
>
> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>> On 23 May 2017 at 17:17, sebb <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)

Bruno P. Kinoshita-3
Hi all,

There is a patch [1] for LANG-1339 [2] that I would like to merge. The discussion around this issue can be found in the rest of this e-mail thread.

The patch basically deprecates the existing classes that depend on java.desktop, and provide alternative implementations. The previous classes used java.desktop classes for the PropertyChangeListener. And the alternative ones instead use Java 7's java.util.Observer.


This will make it easier to provide [lang] as java 9, without requiring users to include a dependency to java.desktop.
Planning to merge it during the next week if there are no objections here.

Thanks,
Bruno


[1] https://github.com/apache/commons-lang/pull/275

[2] https://issues.apache.org/jira/browse/LANG-1339



________________________________From: Benedikt Ritter <[hidden email]>
To: Commons Developers List <[hidden email]>
Sent: Monday, 5 June 2017 10:49 PM
Subject: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)




> Am 25.05.2017 um 18:23 schrieb Oliver Heger <[hidden email]>:
>
>
>
> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>> On 23 May 2017 at 17:17, sebb <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]

>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123