You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2017/05/21 23:56:21 UTC
[LANG] Thoughts about Lang 4.0
Hi,
I think the time has come to start thinking about Lang 4.0. A new major release is a chance to clean up stuff and get rid of APIs we don’t need anymore/don’t want to maintain anymore. Lang has become rather large. It’s description still is
„Lang provides a host of helper utilities for the java.lang API […]"
When I look at Lang I see a lot of stuff which has nothing to do with the java.lang package. I think our aim for 4.0 should be to get back to that again. I like the approach we took with math. Splitting a large package down into smaller individual components is a good idea. So my proposal is to split out more new components from Lang like we did with commons-text and deprecate that stuff in lang. Then we can start with Lang 4.0 and remove all that stuff.
Here are some components I think we could extract from Lang:
- commons-system: a library focused on working with system properties and detection of the operation system, system’s architecture and Java version
- commons-concurrent: a library providing additional abstractions and implementations for the java.util.concurrent package
- commons-reflect: a library which helps working with reflection (where is the line to beanutils here?)
- commons-date: a library which helps working with the java.util.Date and java.util.Calendar APIs
Furthermore I’d remove the o.a.c.lang3.event package. The stuff in o.a.c.lang3.math could maybe find a new home in one of the commons-math components.
The o.a.c.lang3.builder package fits into Lang 4.0 but I’d rename it to o.a.c.lang4.object (if that’s possible). Further more I’d remove the Builder interface.
The o.a.c.lang3.mutable and o.a.c.lang3.tuple package as well as the o.a.c.lang3.exception package can stay as they are.
WDYT?
Benedikt
Re: [LANG] Thoughts about Lang 4.0
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
I think +0 for #1, +1 for #2, and +1 for (#4 or #5). -1 for #3 (though +1 for a 3.7 deprecating these methods).
For 4.0, I wonder if we could find a replacement for the property listeners from java.beans, or might be simpler just remove the property listeners, and have a simple interface for specifying the possible life cycle of a circuit breaker (similar to what Elastic Search does).
I believe I was possibly responsible for introducing it in [lang], so happy to prepare as many development cycles as necessary to help sorting this out, and perhaps stepping up as a release manager for the first time to prepare some releases of lang.
Cheers
Bruno________________________________
From: Stephen Colebourne <sc...@joda.org>
To: Commons Developers List <de...@commons.apache.org>
Sent: Tuesday, 23 May 2017 11:18 PM
Subject: Re: [LANG] Thoughts about Lang 4.0
On 23 May 2017 at 11:54, sebb <se...@gmail.com> 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.
I will note that the JDK is removing methods due to exactly the same
issue - modular Java is quite disruptive..
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
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".
Options that remove the methods:
3) Make a backwards incompatible change to remove the bad methods in
v3.7 (no package name change)
4) Make a backwards incompatible change to remove the bad methods in
v4.0 (no package name change)
5) Make a backwards incompatible change to remove the bad methods in
v4.0 (with package name change)
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Dave Brosius <db...@apache.org>.
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" <ch...@gmail.com> wrote:
>
>
>> On May 24, 2017, at 10:33 AM, Dave Brosius <db...@apache.org> 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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Matt Benson <mb...@apache.org>.
On May 24, 2017 9:42 AM, "Rob Tompkins" <ch...@gmail.com> wrote:
> On May 24, 2017, at 10:33 AM, Dave Brosius <db...@apache.org> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Rob Tompkins <ch...@gmail.com>.
> On May 24, 2017, at 10:33 AM, Dave Brosius <db...@apache.org> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Dave Brosius <db...@apache.org>.
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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, May 25, 2017 at 9:41 AM, Stephen Colebourne <sc...@joda.org>
wrote:
> On 25 May 2017 at 17:23, Oliver Heger <ol...@oliver-heger.de>
> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: [LANG] Thoughts about Lang 4.0
Posted by Stephen Colebourne <sc...@joda.org>.
On 25 May 2017 at 17:23, Oliver Heger <ol...@oliver-heger.de> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by Stephen Colebourne <sc...@joda.org>.
On 10 June 2018 at 00:02, Bruno P. Kinoshita
<br...@yahoo.com.br.invalid> wrote:
> Yes, that's my understanding. We would use require static on java.desktop, but users wouldn't have any issues as long as they did not use the version of the class that requires java.desktop.
>
> If the user want/needs to use those classes, then they have to add the dependency to java.desktop in their code.
When [lang] is used in classpath mode, there is no problem as
java.desktop is included anyway.
When [lang] is used in module mode, the user should get a compile
error unless they add the java.desktop dependency (because their code
will be using the java.desktop classes directly, so their code won't
compile).
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
Yes, that's my understanding. We would use require static on java.desktop, but users wouldn't have any issues as long as they did not use the version of the class that requires java.desktop.
If the user want/needs to use those classes, then they have to add the dependency to java.desktop in their code.
Otherwise, the user just would have to update his/her code to use the new classes (the pull request is about providing this alternative).
Not perfect, but after a few releases (1? couple? major?) we can delete the deprecated classes and tests, remove the require static, and forget about this issue (-:
Bruno
________________________________
From: Gary Gregory <ga...@gmail.com>
To: Commons Developers List <de...@commons.apache.org>; Bruno P. Kinoshita <br...@yahoo.com.br>
Sent: Sunday, 10 June 2018 10:56 AM
Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
So the dependency on desktop is declared as optional but it still exists?
Gary
On Sat, Jun 9, 2018, 16:52 Bruno P. Kinoshita
<br...@yahoo.com.br.invalid> wrote:
> 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 <br...@apache.org>
> To: Commons Developers List <de...@commons.apache.org>
> 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 <
> oliver.heger@oliver-heger.de>:
> >
> >
> >
> > Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
> >> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by Gary Gregory <ga...@gmail.com>.
So the dependency on desktop is declared as optional but it still exists?
Gary
On Sat, Jun 9, 2018, 16:52 Bruno P. Kinoshita
<br...@yahoo.com.br.invalid> wrote:
> 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 <br...@apache.org>
> To: Commons Developers List <de...@commons.apache.org>
> 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 <
> oliver.heger@oliver-heger.de>:
> >
> >
> >
> > Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
> >> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by Chas Honton <ch...@honton.org>.
What’s the minimum target jre? If 8 or later, use java.util.BiConsumer. Otherwise, create a custom @FunctionalInterface.
Chas
> On Jun 10, 2018, at 2:52 PM, Bruno P. Kinoshita <br...@yahoo.com.br.INVALID> wrote:
>
> Great catch indeed Gilles.
>
>
> So perhaps just leave the deprecated, with no replacement? And then add a note in the next release that those classes will be removed in the future?
>
> B
>
> ________________________________
> From: Stephen Colebourne <sc...@joda.org>
> To: Commons Developers List <de...@commons.apache.org>
> Sent: Monday, 11 June 2018 9:26 AM
> Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>
>
>
> Good spot. I think that means [lang] would have to have its own copy
> of the JDK interfaces. or just deprecate the functionality without
> replacement.
> Stephen
>
>> On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org> wrote:
>> Hello.
>>
>>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>>
>>> Hi Bruno,
>>>
>>>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>>
>>>> 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.
>>
>>
>> Is it a good idea to use deprecated classes[1] in new code?
>>
>> Regards,
>> Gilles
>>
>> [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>>
>>
>>>>
>>>>
>>>> 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
>>>
>>>
>>> agreed. This seems to be the best what we can do.
>>>
>>> Oliver
>>>
>>>>
>>>>
>>>> [1] https://github.com/apache/commons-lang/pull/275
>>>>
>>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>>
>>>>
>>>>
>>>> ________________________________From: Benedikt Ritter
>>>> <br...@apache.org>
>>>> To: Commons Developers List <de...@commons.apache.org>
>>>> 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
>>>>> <ol...@oliver-heger.de>:
>>>>>
>>>>>
>>>>>
>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>
>>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
Great catch indeed Gilles.
So perhaps just leave the deprecated, with no replacement? And then add a note in the next release that those classes will be removed in the future?
B
________________________________
From: Stephen Colebourne <sc...@joda.org>
To: Commons Developers List <de...@commons.apache.org>
Sent: Monday, 11 June 2018 9:26 AM
Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
Good spot. I think that means [lang] would have to have its own copy
of the JDK interfaces. or just deprecate the functionality without
replacement.
Stephen
On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org> wrote:
> Hello.
>
> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>
>> Hi Bruno,
>>
>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>
>>> 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.
>
>
> Is it a good idea to use deprecated classes[1] in new code?
>
> Regards,
> Gilles
>
> [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>
>
>>>
>>>
>>> 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
>>
>>
>> agreed. This seems to be the best what we can do.
>>
>> Oliver
>>
>>>
>>>
>>> [1] https://github.com/apache/commons-lang/pull/275
>>>
>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>
>>>
>>>
>>> ________________________________From: Benedikt Ritter
>>> <br...@apache.org>
>>> To: Commons Developers List <de...@commons.apache.org>
>>> 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
>>>> <ol...@oliver-heger.de>:
>>>>
>>>>
>>>>
>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>
>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by Pascal Schumacher <pa...@gmx.net>.
Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
> Saw some recent activity around lang 3.8, and remembered about this issue, and then looked for this thread.
>
> Gilles' point is really good! Here's the Java 9 docs with the deprecation warning, copied below as well https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
>
>
> "This class and the Observer interface have been deprecated. The event model supported by Observer and Observable is quite limited, the order of notifications delivered by Observable is unspecified, and state changes are not in one-for-one correspondence with notifications. For a richer event model, consider using the java.beans package. For reliable and ordered messaging among threads, consider using one of the concurrent data structures in the java.util.concurrent package. For reactive streams style programming, see the Flow API."
>
>
>
> So I guess the best we can do right now is add the @deprecated annotations, with an explanation in the javadocs. And also add a note about it in the release notes.
>
> Does that sound like a good plan?
Sounds good to me!
Cheers,
Pascal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
Posted by Matt Sicker <bo...@gmail.com>.
You can use LinkedTransferQueue for inter thread notifications (or
ArrayBlockingQueue). Read side can either block and wait for items to enter
the queue, or you can use atomics to implement low latency forms of those
queues (but high CPU usage).
On Fri, Jul 20, 2018 at 05:06, Gilles <gi...@harfang.homelinux.org> wrote:
> Hi.
>
> On Fri, 20 Jul 2018 09:47:21 +0100, sebb wrote:
> > On 20 July 2018 at 00:09, Bruno P. Kinoshita
> > <br...@yahoo.com.br.invalid> wrote:
> >>>What is the replacement for Observer/Observable recommended by
> >>>the JDK developers?
> >> I believe they suggest to use the PropertyListener which we have
> >> right now, but are in the java.beans module I think.
> >> Alternatively, they also suggest in the javadocs to look into the
> >> java.util.concurrent package if concurrency is important.
> >>
> >> From what I understand about the latter option, it would mean
> >> building your own event-bus or listeners.
>
> I've read that Observer/Observable will not be removed from the
> JDK (but won't be maintained). So, if the shortcomings are OK
> for the purpose at hand, the issue is only the deprecation warning.
>
> Does someone readily knows how to go about implementing an equivalent
> functionality with "java.util.concurrent" classes?
>
> Regards,
> Gilles
>
> >> As for the java.beans, a possible solution to avoid deprecation
> >> right now would be include the java.beans property listeners code in
> >> [lang]. Maybe internal only.
> >
> > AFAIK we cannot copy any JVM code into our codebase, even if marked
> > internal.
> > It would have to be a clean-room implementation.
> >
> >> Bruno
> >>
> >> From: Gilles <gi...@harfang.homelinux.org>
> >> To: dev@commons.apache.org
> >> Sent: Friday, 20 July 2018 11:05 AM
> >> Subject: Re: [LANG] Java 9 problems because of dependencies to
> >> java.desktop
> >>
> >> Hello.
> >>
> >> On Mon, 16 Jul 2018 21:30:00 +0000 (UTC), Bruno P. Kinoshita wrote:
> >>>>What about introducing our own state listener interface? The
> >>>> original
> >>>>interface from the beans package was used just for convenience
> >>>> because
> >>>>it already existed. But it would of course be possible to have a
> >>>> simple
> >>>>functional interface to notify listeners about state changes.
> >>> Hmmm, that's an option as well.
> >>> Looks like they had the beans interface which we used, then later
> >>> we
> >>> had the java.util.Observable for a while, and now they are
> >>> suggesting
> >>> users to move to the beans interface, as one of the alternatives.
> >>> As some Java 9 users possibly wouldn't want to import the
> >>> java.beans
> >>> module, perhaps having this new interface could be an interesting
> >>> alternative.
> >>> I believe we would have to
> >>> [ ] decide whether to introduce an interface similar to
> >>> PropertyListener, or to Observable[ ] if the backward compatibility
> >>> changed, we must deprecate the existing classes
> >>> [ ] release a new version of lang with this new interface and the
> >>> updated circuit breakers[ ] and either delete the deprecated
> >>> classes
> >>> or leave it until for some more releases
> >>> I wonder what others think about this option?
> >>
> >> What is the replacement for Observer/Observable recommended by
> >> the JDK developers?
> >>
> >> Regards,
> >> Gilles
> >>
> >>> Cheers
> >>> Bruno
> >>>
> >>>
> >>> From: Oliver Heger <ol...@oliver-heger.de>
> >>> To: dev@commons.apache.org
> >>> Sent: Tuesday, 17 July 2018 4:13 AM
> >>> Subject: Re: [LANG] Java 9 problems because of dependencies to
> >>> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
> >>>
> >>>
> >>>
> >>> Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
> >>>> Saw some recent activity around lang 3.8, and remembered about
> >>>> this
> >>>> issue, and then looked for this thread.
> >>>>
> >>>> Gilles' point is really good! Here's the Java 9 docs with the
> >>>> deprecation warning, copied below as well
> >>>>
> >>>>
> https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
> >>>>
> >>>>
> >>>> "This class and the Observer interface have been deprecated. The
> >>>> event model supported by Observer and Observable is quite limited,
> >>>> the
> >>>> order of notifications delivered by Observable is unspecified, and
> >>>> state changes are not in one-for-one correspondence with
> >>>> notifications. For a richer event model, consider using the
> >>>> java.beans
> >>>> package. For reliable and ordered messaging among threads,
> >>>> consider
> >>>> using one of the concurrent data structures in the
> >>>> java.util.concurrent package. For reactive streams style
> >>>> programming,
> >>>> see the Flow API."
> >>>>
> >>>>
> >>>>
> >>>> So I guess the best we can do right now is add the @deprecated
> >>>> annotations, with an explanation in the javadocs. And also add a
> >>>> note
> >>>> about it in the release notes.
> >>>>
> >>>> Does that sound like a good plan? Adding a link to this thread in
> >>>> the pull request as well.
> >>>>
> >>>
> >>> What about introducing our own state listener interface? The
> >>> original
> >>> interface from the beans package was used just for convenience
> >>> because
> >>> it already existed. But it would of course be possible to have a
> >>> simple
> >>> functional interface to notify listeners about state changes.
> >>>
> >>> Oliver
> >>>
> >>>>
> >>>> Cheers
> >>>> Bruno
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ________________________________
> >>>> From: Stephen Colebourne <sc...@joda.org>
> >>>> To: Commons Developers List <de...@commons.apache.org>
> >>>> Sent: Monday, 11 June 2018 9:26 AM
> >>>> Subject: Re: [LANG] Java 9 problems because of dependencies to
> >>>> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
> >>>>
> >>>>
> >>>>
> >>>> Good spot. I think that means [lang] would have to have its own
> >>>> copy
> >>>> of the JDK interfaces. or just deprecate the functionality without
> >>>> replacement.
> >>>> Stephen
> >>>>
> >>>> On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org>
> >>>> wrote:
> >>>>> Hello.
> >>>>>
> >>>>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
> >>>>>>
> >>>>>> Hi Bruno,
> >>>>>>
> >>>>>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
> >>>>>>>
> >>>>>>> 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.
> >>>>>
> >>>>>
> >>>>> Is it a good idea to use deprecated classes[1] in new code?
> >>>>>
> >>>>> Regards,
> >>>>> Gilles
> >>>>>
> >>>>> [1]
> >>>>>
> >>>>> https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
> >>>>>
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 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
> >>>>>>
> >>>>>>
> >>>>>> agreed. This seems to be the best what we can do.
> >>>>>>
> >>>>>> Oliver
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> [1] https://github.com/apache/commons-lang/pull/275
> >>>>>>>
> >>>>>>> [2] https://issues.apache.org/jira/browse/LANG-1339
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> ________________________________From: Benedikt Ritter
> >>>>>>> <br...@apache.org>
> >>>>>>> To: Commons Developers List <de...@commons.apache.org>
> >>>>>>> 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
> >>>>>>>> <ol...@oliver-heger.de>:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
> >>>>>>>>>
> >>>>>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> --
Matt Sicker <bo...@gmail.com>
Re: [LANG] Java 9 problems because of dependencies to java.desktop
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
On Fri, 20 Jul 2018 09:47:21 +0100, sebb wrote:
> On 20 July 2018 at 00:09, Bruno P. Kinoshita
> <br...@yahoo.com.br.invalid> wrote:
>>>What is the replacement for Observer/Observable recommended by
>>>the JDK developers?
>> I believe they suggest to use the PropertyListener which we have
>> right now, but are in the java.beans module I think.
>> Alternatively, they also suggest in the javadocs to look into the
>> java.util.concurrent package if concurrency is important.
>>
>> From what I understand about the latter option, it would mean
>> building your own event-bus or listeners.
I've read that Observer/Observable will not be removed from the
JDK (but won't be maintained). So, if the shortcomings are OK
for the purpose at hand, the issue is only the deprecation warning.
Does someone readily knows how to go about implementing an equivalent
functionality with "java.util.concurrent" classes?
Regards,
Gilles
>> As for the java.beans, a possible solution to avoid deprecation
>> right now would be include the java.beans property listeners code in
>> [lang]. Maybe internal only.
>
> AFAIK we cannot copy any JVM code into our codebase, even if marked
> internal.
> It would have to be a clean-room implementation.
>
>> Bruno
>>
>> From: Gilles <gi...@harfang.homelinux.org>
>> To: dev@commons.apache.org
>> Sent: Friday, 20 July 2018 11:05 AM
>> Subject: Re: [LANG] Java 9 problems because of dependencies to
>> java.desktop
>>
>> Hello.
>>
>> On Mon, 16 Jul 2018 21:30:00 +0000 (UTC), Bruno P. Kinoshita wrote:
>>>>What about introducing our own state listener interface? The
>>>> original
>>>>interface from the beans package was used just for convenience
>>>> because
>>>>it already existed. But it would of course be possible to have a
>>>> simple
>>>>functional interface to notify listeners about state changes.
>>> Hmmm, that's an option as well.
>>> Looks like they had the beans interface which we used, then later
>>> we
>>> had the java.util.Observable for a while, and now they are
>>> suggesting
>>> users to move to the beans interface, as one of the alternatives.
>>> As some Java 9 users possibly wouldn't want to import the
>>> java.beans
>>> module, perhaps having this new interface could be an interesting
>>> alternative.
>>> I believe we would have to
>>> [ ] decide whether to introduce an interface similar to
>>> PropertyListener, or to Observable[ ] if the backward compatibility
>>> changed, we must deprecate the existing classes
>>> [ ] release a new version of lang with this new interface and the
>>> updated circuit breakers[ ] and either delete the deprecated
>>> classes
>>> or leave it until for some more releases
>>> I wonder what others think about this option?
>>
>> What is the replacement for Observer/Observable recommended by
>> the JDK developers?
>>
>> Regards,
>> Gilles
>>
>>> Cheers
>>> Bruno
>>>
>>>
>>> From: Oliver Heger <ol...@oliver-heger.de>
>>> To: dev@commons.apache.org
>>> Sent: Tuesday, 17 July 2018 4:13 AM
>>> Subject: Re: [LANG] Java 9 problems because of dependencies to
>>> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>>>
>>>
>>>
>>> Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
>>>> Saw some recent activity around lang 3.8, and remembered about
>>>> this
>>>> issue, and then looked for this thread.
>>>>
>>>> Gilles' point is really good! Here's the Java 9 docs with the
>>>> deprecation warning, copied below as well
>>>>
>>>> https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
>>>>
>>>>
>>>> "This class and the Observer interface have been deprecated. The
>>>> event model supported by Observer and Observable is quite limited,
>>>> the
>>>> order of notifications delivered by Observable is unspecified, and
>>>> state changes are not in one-for-one correspondence with
>>>> notifications. For a richer event model, consider using the
>>>> java.beans
>>>> package. For reliable and ordered messaging among threads,
>>>> consider
>>>> using one of the concurrent data structures in the
>>>> java.util.concurrent package. For reactive streams style
>>>> programming,
>>>> see the Flow API."
>>>>
>>>>
>>>>
>>>> So I guess the best we can do right now is add the @deprecated
>>>> annotations, with an explanation in the javadocs. And also add a
>>>> note
>>>> about it in the release notes.
>>>>
>>>> Does that sound like a good plan? Adding a link to this thread in
>>>> the pull request as well.
>>>>
>>>
>>> What about introducing our own state listener interface? The
>>> original
>>> interface from the beans package was used just for convenience
>>> because
>>> it already existed. But it would of course be possible to have a
>>> simple
>>> functional interface to notify listeners about state changes.
>>>
>>> Oliver
>>>
>>>>
>>>> Cheers
>>>> Bruno
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________
>>>> From: Stephen Colebourne <sc...@joda.org>
>>>> To: Commons Developers List <de...@commons.apache.org>
>>>> Sent: Monday, 11 June 2018 9:26 AM
>>>> Subject: Re: [LANG] Java 9 problems because of dependencies to
>>>> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>>>>
>>>>
>>>>
>>>> Good spot. I think that means [lang] would have to have its own
>>>> copy
>>>> of the JDK interfaces. or just deprecate the functionality without
>>>> replacement.
>>>> Stephen
>>>>
>>>> On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>> Hello.
>>>>>
>>>>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>>>>>
>>>>>> Hi Bruno,
>>>>>>
>>>>>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>>
>>>>> Is it a good idea to use deprecated classes[1] in new code?
>>>>>
>>>>> Regards,
>>>>> Gilles
>>>>>
>>>>> [1]
>>>>>
>>>>> https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>>>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> agreed. This seems to be the best what we can do.
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1] https://github.com/apache/commons-lang/pull/275
>>>>>>>
>>>>>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________From: Benedikt Ritter
>>>>>>> <br...@apache.org>
>>>>>>> To: Commons Developers List <de...@commons.apache.org>
>>>>>>> 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
>>>>>>>> <ol...@oliver-heger.de>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>>>>
>>>>>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
Posted by sebb <se...@gmail.com>.
On 20 July 2018 at 00:09, Bruno P. Kinoshita
<br...@yahoo.com.br.invalid> wrote:
>>What is the replacement for Observer/Observable recommended by
>>the JDK developers?
> I believe they suggest to use the PropertyListener which we have right now, but are in the java.beans module I think.
> Alternatively, they also suggest in the javadocs to look into the java.util.concurrent package if concurrency is important.
>
> From what I understand about the latter option, it would mean building your own event-bus or listeners.
> As for the java.beans, a possible solution to avoid deprecation right now would be include the java.beans property listeners code in [lang]. Maybe internal only.
AFAIK we cannot copy any JVM code into our codebase, even if marked internal.
It would have to be a clean-room implementation.
> Bruno
>
> From: Gilles <gi...@harfang.homelinux.org>
> To: dev@commons.apache.org
> Sent: Friday, 20 July 2018 11:05 AM
> Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop
>
> Hello.
>
> On Mon, 16 Jul 2018 21:30:00 +0000 (UTC), Bruno P. Kinoshita wrote:
>>>What about introducing our own state listener interface? The original
>>>interface from the beans package was used just for convenience
>>> because
>>>it already existed. But it would of course be possible to have a
>>> simple
>>>functional interface to notify listeners about state changes.
>> Hmmm, that's an option as well.
>> Looks like they had the beans interface which we used, then later we
>> had the java.util.Observable for a while, and now they are suggesting
>> users to move to the beans interface, as one of the alternatives.
>> As some Java 9 users possibly wouldn't want to import the java.beans
>> module, perhaps having this new interface could be an interesting
>> alternative.
>> I believe we would have to
>> [ ] decide whether to introduce an interface similar to
>> PropertyListener, or to Observable[ ] if the backward compatibility
>> changed, we must deprecate the existing classes
>> [ ] release a new version of lang with this new interface and the
>> updated circuit breakers[ ] and either delete the deprecated classes
>> or leave it until for some more releases
>> I wonder what others think about this option?
>
> What is the replacement for Observer/Observable recommended by
> the JDK developers?
>
> Regards,
> Gilles
>
>> Cheers
>> Bruno
>>
>>
>> From: Oliver Heger <ol...@oliver-heger.de>
>> To: dev@commons.apache.org
>> Sent: Tuesday, 17 July 2018 4:13 AM
>> Subject: Re: [LANG] Java 9 problems because of dependencies to
>> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>>
>>
>>
>> Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
>>> Saw some recent activity around lang 3.8, and remembered about this
>>> issue, and then looked for this thread.
>>>
>>> Gilles' point is really good! Here's the Java 9 docs with the
>>> deprecation warning, copied below as well
>>> https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
>>>
>>>
>>> "This class and the Observer interface have been deprecated. The
>>> event model supported by Observer and Observable is quite limited, the
>>> order of notifications delivered by Observable is unspecified, and
>>> state changes are not in one-for-one correspondence with
>>> notifications. For a richer event model, consider using the java.beans
>>> package. For reliable and ordered messaging among threads, consider
>>> using one of the concurrent data structures in the
>>> java.util.concurrent package. For reactive streams style programming,
>>> see the Flow API."
>>>
>>>
>>>
>>> So I guess the best we can do right now is add the @deprecated
>>> annotations, with an explanation in the javadocs. And also add a note
>>> about it in the release notes.
>>>
>>> Does that sound like a good plan? Adding a link to this thread in
>>> the pull request as well.
>>>
>>
>> What about introducing our own state listener interface? The original
>> interface from the beans package was used just for convenience
>> because
>> it already existed. But it would of course be possible to have a
>> simple
>> functional interface to notify listeners about state changes.
>>
>> Oliver
>>
>>>
>>> Cheers
>>> Bruno
>>>
>>>
>>>
>>>
>>> ________________________________
>>> From: Stephen Colebourne <sc...@joda.org>
>>> To: Commons Developers List <de...@commons.apache.org>
>>> Sent: Monday, 11 June 2018 9:26 AM
>>> Subject: Re: [LANG] Java 9 problems because of dependencies to
>>> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>>>
>>>
>>>
>>> Good spot. I think that means [lang] would have to have its own copy
>>> of the JDK interfaces. or just deprecate the functionality without
>>> replacement.
>>> Stephen
>>>
>>> On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org>
>>> wrote:
>>>> Hello.
>>>>
>>>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>>>>
>>>>> Hi Bruno,
>>>>>
>>>>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>>>>
>>>>>> 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.
>>>>
>>>>
>>>> Is it a good idea to use deprecated classes[1] in new code?
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>> [1]
>>>> https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>> agreed. This seems to be the best what we can do.
>>>>>
>>>>> Oliver
>>>>>
>>>>>>
>>>>>>
>>>>>> [1] https://github.com/apache/commons-lang/pull/275
>>>>>>
>>>>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>>>>
>>>>>>
>>>>>>
>>>>>> ________________________________From: Benedikt Ritter
>>>>>> <br...@apache.org>
>>>>>> To: Commons Developers List <de...@commons.apache.org>
>>>>>> 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
>>>>>>> <ol...@oliver-heger.de>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>>>
>>>>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
>What is the replacement for Observer/Observable recommended by
>the JDK developers?
I believe they suggest to use the PropertyListener which we have right now, but are in the java.beans module I think.
Alternatively, they also suggest in the javadocs to look into the java.util.concurrent package if concurrency is important.
From what I understand about the latter option, it would mean building your own event-bus or listeners.
As for the java.beans, a possible solution to avoid deprecation right now would be include the java.beans property listeners code in [lang]. Maybe internal only.
Bruno
From: Gilles <gi...@harfang.homelinux.org>
To: dev@commons.apache.org
Sent: Friday, 20 July 2018 11:05 AM
Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop
Hello.
On Mon, 16 Jul 2018 21:30:00 +0000 (UTC), Bruno P. Kinoshita wrote:
>>What about introducing our own state listener interface? The original
>>interface from the beans package was used just for convenience
>> because
>>it already existed. But it would of course be possible to have a
>> simple
>>functional interface to notify listeners about state changes.
> Hmmm, that's an option as well.
> Looks like they had the beans interface which we used, then later we
> had the java.util.Observable for a while, and now they are suggesting
> users to move to the beans interface, as one of the alternatives.
> As some Java 9 users possibly wouldn't want to import the java.beans
> module, perhaps having this new interface could be an interesting
> alternative.
> I believe we would have to
> [ ] decide whether to introduce an interface similar to
> PropertyListener, or to Observable[ ] if the backward compatibility
> changed, we must deprecate the existing classes
> [ ] release a new version of lang with this new interface and the
> updated circuit breakers[ ] and either delete the deprecated classes
> or leave it until for some more releases
> I wonder what others think about this option?
What is the replacement for Observer/Observable recommended by
the JDK developers?
Regards,
Gilles
> Cheers
> Bruno
>
>
> From: Oliver Heger <ol...@oliver-heger.de>
> To: dev@commons.apache.org
> Sent: Tuesday, 17 July 2018 4:13 AM
> Subject: Re: [LANG] Java 9 problems because of dependencies to
> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>
>
>
> Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
>> Saw some recent activity around lang 3.8, and remembered about this
>> issue, and then looked for this thread.
>>
>> Gilles' point is really good! Here's the Java 9 docs with the
>> deprecation warning, copied below as well
>> https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
>>
>>
>> "This class and the Observer interface have been deprecated. The
>> event model supported by Observer and Observable is quite limited, the
>> order of notifications delivered by Observable is unspecified, and
>> state changes are not in one-for-one correspondence with
>> notifications. For a richer event model, consider using the java.beans
>> package. For reliable and ordered messaging among threads, consider
>> using one of the concurrent data structures in the
>> java.util.concurrent package. For reactive streams style programming,
>> see the Flow API."
>>
>>
>>
>> So I guess the best we can do right now is add the @deprecated
>> annotations, with an explanation in the javadocs. And also add a note
>> about it in the release notes.
>>
>> Does that sound like a good plan? Adding a link to this thread in
>> the pull request as well.
>>
>
> What about introducing our own state listener interface? The original
> interface from the beans package was used just for convenience
> because
> it already existed. But it would of course be possible to have a
> simple
> functional interface to notify listeners about state changes.
>
> Oliver
>
>>
>> Cheers
>> Bruno
>>
>>
>>
>>
>> ________________________________
>> From: Stephen Colebourne <sc...@joda.org>
>> To: Commons Developers List <de...@commons.apache.org>
>> Sent: Monday, 11 June 2018 9:26 AM
>> Subject: Re: [LANG] Java 9 problems because of dependencies to
>> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>>
>>
>>
>> Good spot. I think that means [lang] would have to have its own copy
>> of the JDK interfaces. or just deprecate the functionality without
>> replacement.
>> Stephen
>>
>> On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>> Hello.
>>>
>>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>>>
>>>> Hi Bruno,
>>>>
>>>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>>>
>>>>> 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.
>>>
>>>
>>> Is it a good idea to use deprecated classes[1] in new code?
>>>
>>> Regards,
>>> Gilles
>>>
>>> [1]
>>> https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>>>
>>>
>>>>>
>>>>>
>>>>> 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
>>>>
>>>>
>>>> agreed. This seems to be the best what we can do.
>>>>
>>>> Oliver
>>>>
>>>>>
>>>>>
>>>>> [1] https://github.com/apache/commons-lang/pull/275
>>>>>
>>>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>>>
>>>>>
>>>>>
>>>>> ________________________________From: Benedikt Ritter
>>>>> <br...@apache.org>
>>>>> To: Commons Developers List <de...@commons.apache.org>
>>>>> 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
>>>>>> <ol...@oliver-heger.de>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>>
>>>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
Posted by Gilles <gi...@harfang.homelinux.org>.
Hello.
On Mon, 16 Jul 2018 21:30:00 +0000 (UTC), Bruno P. Kinoshita wrote:
>>What about introducing our own state listener interface? The original
>>interface from the beans package was used just for convenience
>> because
>>it already existed. But it would of course be possible to have a
>> simple
>>functional interface to notify listeners about state changes.
> Hmmm, that's an option as well.
> Looks like they had the beans interface which we used, then later we
> had the java.util.Observable for a while, and now they are suggesting
> users to move to the beans interface, as one of the alternatives.
> As some Java 9 users possibly wouldn't want to import the java.beans
> module, perhaps having this new interface could be an interesting
> alternative.
> I believe we would have to
> [ ] decide whether to introduce an interface similar to
> PropertyListener, or to Observable[ ] if the backward compatibility
> changed, we must deprecate the existing classes
> [ ] release a new version of lang with this new interface and the
> updated circuit breakers[ ] and either delete the deprecated classes
> or leave it until for some more releases
> I wonder what others think about this option?
What is the replacement for Observer/Observable recommended by
the JDK developers?
Regards,
Gilles
> Cheers
> Bruno
>
>
> From: Oliver Heger <ol...@oliver-heger.de>
> To: dev@commons.apache.org
> Sent: Tuesday, 17 July 2018 4:13 AM
> Subject: Re: [LANG] Java 9 problems because of dependencies to
> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>
>
>
> Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
>> Saw some recent activity around lang 3.8, and remembered about this
>> issue, and then looked for this thread.
>>
>> Gilles' point is really good! Here's the Java 9 docs with the
>> deprecation warning, copied below as well
>> https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
>>
>>
>> "This class and the Observer interface have been deprecated. The
>> event model supported by Observer and Observable is quite limited, the
>> order of notifications delivered by Observable is unspecified, and
>> state changes are not in one-for-one correspondence with
>> notifications. For a richer event model, consider using the java.beans
>> package. For reliable and ordered messaging among threads, consider
>> using one of the concurrent data structures in the
>> java.util.concurrent package. For reactive streams style programming,
>> see the Flow API."
>>
>>
>>
>> So I guess the best we can do right now is add the @deprecated
>> annotations, with an explanation in the javadocs. And also add a note
>> about it in the release notes.
>>
>> Does that sound like a good plan? Adding a link to this thread in
>> the pull request as well.
>>
>
> What about introducing our own state listener interface? The original
> interface from the beans package was used just for convenience
> because
> it already existed. But it would of course be possible to have a
> simple
> functional interface to notify listeners about state changes.
>
> Oliver
>
>>
>> Cheers
>> Bruno
>>
>>
>>
>>
>> ________________________________
>> From: Stephen Colebourne <sc...@joda.org>
>> To: Commons Developers List <de...@commons.apache.org>
>> Sent: Monday, 11 June 2018 9:26 AM
>> Subject: Re: [LANG] Java 9 problems because of dependencies to
>> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>>
>>
>>
>> Good spot. I think that means [lang] would have to have its own copy
>> of the JDK interfaces. or just deprecate the functionality without
>> replacement.
>> Stephen
>>
>> On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>> Hello.
>>>
>>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>>>
>>>> Hi Bruno,
>>>>
>>>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>>>
>>>>> 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.
>>>
>>>
>>> Is it a good idea to use deprecated classes[1] in new code?
>>>
>>> Regards,
>>> Gilles
>>>
>>> [1]
>>> https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>>>
>>>
>>>>>
>>>>>
>>>>> 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
>>>>
>>>>
>>>> agreed. This seems to be the best what we can do.
>>>>
>>>> Oliver
>>>>
>>>>>
>>>>>
>>>>> [1] https://github.com/apache/commons-lang/pull/275
>>>>>
>>>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>>>
>>>>>
>>>>>
>>>>> ________________________________From: Benedikt Ritter
>>>>> <br...@apache.org>
>>>>> To: Commons Developers List <de...@commons.apache.org>
>>>>> 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
>>>>>> <ol...@oliver-heger.de>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>>
>>>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 17.07.2018 um 19:11 schrieb Pascal Schumacher:
> I think we should deprecate without replacement.
>
> There are already plenty Apache 2.0 licensed libraries offering circuit
> breaker implementations:
>
> https://github.com/Netflix/Hystrix
> https://github.com/jhalterman/failsafe
> https://github.com/resilience4j/resilience4j
This seems to be a quite drastic solution to me. In the past we have
deprecated classes that became obsolete because replacements were added
to the JDK.
But here situation is different. The classes work as documented, and
simply deprecating them without replacement is not very user friendly.
This would pretty much contradict our long tradition of preserving
backwards compatibility as much as possible.
Oliver
>
> Cheers,
> Pascal
>
> Am 16.07.2018 um 23:30 schrieb Bruno P. Kinoshita:
>>> What about introducing our own state listener interface? The original
>>> interface from the beans package was used just for convenience because
>>> it already existed. But it would of course be possible to have a simple
>>> functional interface to notify listeners about state changes.
>> Hmmm, that's an option as well.
>> Looks like they had the beans interface which we used, then later we
>> had the java.util.Observable for a while, and now they are suggesting
>> users to move to the beans interface, as one of the alternatives.
>> As some Java 9 users possibly wouldn't want to import the java.beans
>> module, perhaps having this new interface could be an interesting
>> alternative.
>> I believe we would have to
>> [ ] decide whether to introduce an interface similar to
>> PropertyListener, or to Observable[ ] if the backward compatibility
>> changed, we must deprecate the existing classes
>> [ ] release a new version of lang with this new interface and the
>> updated circuit breakers[ ] and either delete the deprecated classes
>> or leave it until for some more releases
>> I wonder what others think about this option?
>>
>> Cheers
>> Bruno
>>
>>
>> From: Oliver Heger <ol...@oliver-heger.de>
>> To: dev@commons.apache.org
>> Sent: Tuesday, 17 July 2018 4:13 AM
>> Subject: Re: [LANG] Java 9 problems because of dependencies to
>> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>>
>>
>> Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
>>> Saw some recent activity around lang 3.8, and remembered about this
>>> issue, and then looked for this thread.
>>>
>>> Gilles' point is really good! Here's the Java 9 docs with the
>>> deprecation warning, copied below as well
>>> https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
>>>
>>>
>>>
>>> "This class and the Observer interface have been deprecated. The
>>> event model supported by Observer and Observable is quite limited,
>>> the order of notifications delivered by Observable is unspecified,
>>> and state changes are not in one-for-one correspondence with
>>> notifications. For a richer event model, consider using the
>>> java.beans package. For reliable and ordered messaging among
>>> threads, consider using one of the concurrent data structures in the
>>> java.util.concurrent package. For reactive streams style programming,
>>> see the Flow API."
>>>
>>>
>>>
>>> So I guess the best we can do right now is add the @deprecated
>>> annotations, with an explanation in the javadocs. And also add a note
>>> about it in the release notes.
>>>
>>> Does that sound like a good plan? Adding a link to this thread in the
>>> pull request as well.
>>>
>> What about introducing our own state listener interface? The original
>> interface from the beans package was used just for convenience because
>> it already existed. But it would of course be possible to have a simple
>> functional interface to notify listeners about state changes.
>>
>> Oliver
>>
>>> Cheers
>>> Bruno
>>>
>>>
>>>
>>>
>>> ________________________________
>>> From: Stephen Colebourne <sc...@joda.org>
>>> To: Commons Developers List <de...@commons.apache.org>
>>> Sent: Monday, 11 June 2018 9:26 AM
>>> Subject: Re: [LANG] Java 9 problems because of dependencies to
>>> java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>>>
>>>
>>>
>>> Good spot. I think that means [lang] would have to have its own copy
>>> of the JDK interfaces. or just deprecate the functionality without
>>> replacement.
>>> Stephen
>>>
>>> On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org> wrote:
>>>> Hello.
>>>>
>>>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>>>> Hi Bruno,
>>>>>
>>>>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>>>> 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.
>>>>
>>>> Is it a good idea to use deprecated classes[1] in new code?
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>> [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>>>>
>>>>
>>>>>>
>>>>>> 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
>>>>>
>>>>> agreed. This seems to be the best what we can do.
>>>>>
>>>>> Oliver
>>>>>
>>>>>>
>>>>>> [1] https://github.com/apache/commons-lang/pull/275
>>>>>>
>>>>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>>>>
>>>>>>
>>>>>>
>>>>>> ________________________________From: Benedikt Ritter
>>>>>> <br...@apache.org>
>>>>>> To: Commons Developers List <de...@commons.apache.org>
>>>>>> 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
>>>>>>> <ol...@oliver-heger.de>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by Pascal Schumacher <pa...@gmx.net>.
I think we should deprecate without replacement.
There are already plenty Apache 2.0 licensed libraries offering circuit
breaker implementations:
https://github.com/Netflix/Hystrix
https://github.com/jhalterman/failsafe
https://github.com/resilience4j/resilience4j
Cheers,
Pascal
Am 16.07.2018 um 23:30 schrieb Bruno P. Kinoshita:
>> What about introducing our own state listener interface? The original
>> interface from the beans package was used just for convenience because
>> it already existed. But it would of course be possible to have a simple
>> functional interface to notify listeners about state changes.
> Hmmm, that's an option as well.
> Looks like they had the beans interface which we used, then later we had the java.util.Observable for a while, and now they are suggesting users to move to the beans interface, as one of the alternatives.
> As some Java 9 users possibly wouldn't want to import the java.beans module, perhaps having this new interface could be an interesting alternative.
> I believe we would have to
> [ ] decide whether to introduce an interface similar to PropertyListener, or to Observable[ ] if the backward compatibility changed, we must deprecate the existing classes
> [ ] release a new version of lang with this new interface and the updated circuit breakers[ ] and either delete the deprecated classes or leave it until for some more releases
> I wonder what others think about this option?
>
> Cheers
> Bruno
>
>
> From: Oliver Heger <ol...@oliver-heger.de>
> To: dev@commons.apache.org
> Sent: Tuesday, 17 July 2018 4:13 AM
> Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>
>
>
> Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
>> Saw some recent activity around lang 3.8, and remembered about this issue, and then looked for this thread.
>>
>> Gilles' point is really good! Here's the Java 9 docs with the deprecation warning, copied below as well https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
>>
>>
>> "This class and the Observer interface have been deprecated. The event model supported by Observer and Observable is quite limited, the order of notifications delivered by Observable is unspecified, and state changes are not in one-for-one correspondence with notifications. For a richer event model, consider using the java.beans package. For reliable and ordered messaging among threads, consider using one of the concurrent data structures in the java.util.concurrent package. For reactive streams style programming, see the Flow API."
>>
>>
>>
>> So I guess the best we can do right now is add the @deprecated annotations, with an explanation in the javadocs. And also add a note about it in the release notes.
>>
>> Does that sound like a good plan? Adding a link to this thread in the pull request as well.
>>
> What about introducing our own state listener interface? The original
> interface from the beans package was used just for convenience because
> it already existed. But it would of course be possible to have a simple
> functional interface to notify listeners about state changes.
>
> Oliver
>
>> Cheers
>> Bruno
>>
>>
>>
>>
>> ________________________________
>> From: Stephen Colebourne <sc...@joda.org>
>> To: Commons Developers List <de...@commons.apache.org>
>> Sent: Monday, 11 June 2018 9:26 AM
>> Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>>
>>
>>
>> Good spot. I think that means [lang] would have to have its own copy
>> of the JDK interfaces. or just deprecate the functionality without
>> replacement.
>> Stephen
>>
>> On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org> wrote:
>>> Hello.
>>>
>>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>>> Hi Bruno,
>>>>
>>>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>>> 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.
>>>
>>> Is it a good idea to use deprecated classes[1] in new code?
>>>
>>> Regards,
>>> Gilles
>>>
>>> [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>>>
>>>
>>>>>
>>>>> 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
>>>>
>>>> agreed. This seems to be the best what we can do.
>>>>
>>>> Oliver
>>>>
>>>>>
>>>>> [1] https://github.com/apache/commons-lang/pull/275
>>>>>
>>>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>>>
>>>>>
>>>>>
>>>>> ________________________________From: Benedikt Ritter
>>>>> <br...@apache.org>
>>>>> To: Commons Developers List <de...@commons.apache.org>
>>>>> 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
>>>>>> <ol...@oliver-heger.de>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
>What about introducing our own state listener interface? The original
>interface from the beans package was used just for convenience because
>it already existed. But it would of course be possible to have a simple
>functional interface to notify listeners about state changes.
Hmmm, that's an option as well.
Looks like they had the beans interface which we used, then later we had the java.util.Observable for a while, and now they are suggesting users to move to the beans interface, as one of the alternatives.
As some Java 9 users possibly wouldn't want to import the java.beans module, perhaps having this new interface could be an interesting alternative.
I believe we would have to
[ ] decide whether to introduce an interface similar to PropertyListener, or to Observable[ ] if the backward compatibility changed, we must deprecate the existing classes
[ ] release a new version of lang with this new interface and the updated circuit breakers[ ] and either delete the deprecated classes or leave it until for some more releases
I wonder what others think about this option?
Cheers
Bruno
From: Oliver Heger <ol...@oliver-heger.de>
To: dev@commons.apache.org
Sent: Tuesday, 17 July 2018 4:13 AM
Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
> Saw some recent activity around lang 3.8, and remembered about this issue, and then looked for this thread.
>
> Gilles' point is really good! Here's the Java 9 docs with the deprecation warning, copied below as well https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
>
>
> "This class and the Observer interface have been deprecated. The event model supported by Observer and Observable is quite limited, the order of notifications delivered by Observable is unspecified, and state changes are not in one-for-one correspondence with notifications. For a richer event model, consider using the java.beans package. For reliable and ordered messaging among threads, consider using one of the concurrent data structures in the java.util.concurrent package. For reactive streams style programming, see the Flow API."
>
>
>
> So I guess the best we can do right now is add the @deprecated annotations, with an explanation in the javadocs. And also add a note about it in the release notes.
>
> Does that sound like a good plan? Adding a link to this thread in the pull request as well.
>
What about introducing our own state listener interface? The original
interface from the beans package was used just for convenience because
it already existed. But it would of course be possible to have a simple
functional interface to notify listeners about state changes.
Oliver
>
> Cheers
> Bruno
>
>
>
>
> ________________________________
> From: Stephen Colebourne <sc...@joda.org>
> To: Commons Developers List <de...@commons.apache.org>
> Sent: Monday, 11 June 2018 9:26 AM
> Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>
>
>
> Good spot. I think that means [lang] would have to have its own copy
> of the JDK interfaces. or just deprecate the functionality without
> replacement.
> Stephen
>
> On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org> wrote:
>> Hello.
>>
>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>>
>>> Hi Bruno,
>>>
>>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>>
>>>> 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.
>>
>>
>> Is it a good idea to use deprecated classes[1] in new code?
>>
>> Regards,
>> Gilles
>>
>> [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>>
>>
>>>>
>>>>
>>>> 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
>>>
>>>
>>> agreed. This seems to be the best what we can do.
>>>
>>> Oliver
>>>
>>>>
>>>>
>>>> [1] https://github.com/apache/commons-lang/pull/275
>>>>
>>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>>
>>>>
>>>>
>>>> ________________________________From: Benedikt Ritter
>>>> <br...@apache.org>
>>>> To: Commons Developers List <de...@commons.apache.org>
>>>> 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
>>>>> <ol...@oliver-heger.de>:
>>>>>
>>>>>
>>>>>
>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>
>>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
> Saw some recent activity around lang 3.8, and remembered about this issue, and then looked for this thread.
>
> Gilles' point is really good! Here's the Java 9 docs with the deprecation warning, copied below as well https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
>
>
> "This class and the Observer interface have been deprecated. The event model supported by Observer and Observable is quite limited, the order of notifications delivered by Observable is unspecified, and state changes are not in one-for-one correspondence with notifications. For a richer event model, consider using the java.beans package. For reliable and ordered messaging among threads, consider using one of the concurrent data structures in the java.util.concurrent package. For reactive streams style programming, see the Flow API."
>
>
>
> So I guess the best we can do right now is add the @deprecated annotations, with an explanation in the javadocs. And also add a note about it in the release notes.
>
> Does that sound like a good plan? Adding a link to this thread in the pull request as well.
>
What about introducing our own state listener interface? The original
interface from the beans package was used just for convenience because
it already existed. But it would of course be possible to have a simple
functional interface to notify listeners about state changes.
Oliver
>
> Cheers
> Bruno
>
>
>
>
> ________________________________
> From: Stephen Colebourne <sc...@joda.org>
> To: Commons Developers List <de...@commons.apache.org>
> Sent: Monday, 11 June 2018 9:26 AM
> Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
>
>
>
> Good spot. I think that means [lang] would have to have its own copy
> of the JDK interfaces. or just deprecate the functionality without
> replacement.
> Stephen
>
> On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org> wrote:
>> Hello.
>>
>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>>
>>> Hi Bruno,
>>>
>>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>>
>>>> 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.
>>
>>
>> Is it a good idea to use deprecated classes[1] in new code?
>>
>> Regards,
>> Gilles
>>
>> [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>>
>>
>>>>
>>>>
>>>> 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
>>>
>>>
>>> agreed. This seems to be the best what we can do.
>>>
>>> Oliver
>>>
>>>>
>>>>
>>>> [1] https://github.com/apache/commons-lang/pull/275
>>>>
>>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>>
>>>>
>>>>
>>>> ________________________________From: Benedikt Ritter
>>>> <br...@apache.org>
>>>> To: Commons Developers List <de...@commons.apache.org>
>>>> 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
>>>>> <ol...@oliver-heger.de>:
>>>>>
>>>>>
>>>>>
>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>
>>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
Saw some recent activity around lang 3.8, and remembered about this issue, and then looked for this thread.
Gilles' point is really good! Here's the Java 9 docs with the deprecation warning, copied below as well https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
"This class and the Observer interface have been deprecated. The event model supported by Observer and Observable is quite limited, the order of notifications delivered by Observable is unspecified, and state changes are not in one-for-one correspondence with notifications. For a richer event model, consider using the java.beans package. For reliable and ordered messaging among threads, consider using one of the concurrent data structures in the java.util.concurrent package. For reactive streams style programming, see the Flow API."
So I guess the best we can do right now is add the @deprecated annotations, with an explanation in the javadocs. And also add a note about it in the release notes.
Does that sound like a good plan? Adding a link to this thread in the pull request as well.
Cheers
Bruno
________________________________
From: Stephen Colebourne <sc...@joda.org>
To: Commons Developers List <de...@commons.apache.org>
Sent: Monday, 11 June 2018 9:26 AM
Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
Good spot. I think that means [lang] would have to have its own copy
of the JDK interfaces. or just deprecate the functionality without
replacement.
Stephen
On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org> wrote:
> Hello.
>
> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>
>> Hi Bruno,
>>
>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>
>>> 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.
>
>
> Is it a good idea to use deprecated classes[1] in new code?
>
> Regards,
> Gilles
>
> [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>
>
>>>
>>>
>>> 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
>>
>>
>> agreed. This seems to be the best what we can do.
>>
>> Oliver
>>
>>>
>>>
>>> [1] https://github.com/apache/commons-lang/pull/275
>>>
>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>
>>>
>>>
>>> ________________________________From: Benedikt Ritter
>>> <br...@apache.org>
>>> To: Commons Developers List <de...@commons.apache.org>
>>> 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
>>>> <ol...@oliver-heger.de>:
>>>>
>>>>
>>>>
>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>
>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by Stephen Colebourne <sc...@joda.org>.
Good spot. I think that means [lang] would have to have its own copy
of the JDK interfaces. or just deprecate the functionality without
replacement.
Stephen
On 10 June 2018 at 22:11, Gilles <gi...@harfang.homelinux.org> wrote:
> Hello.
>
> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>
>> Hi Bruno,
>>
>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>
>>> 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.
>
>
> Is it a good idea to use deprecated classes[1] in new code?
>
> Regards,
> Gilles
>
> [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>
>
>>>
>>>
>>> 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
>>
>>
>> agreed. This seems to be the best what we can do.
>>
>> Oliver
>>
>>>
>>>
>>> [1] https://github.com/apache/commons-lang/pull/275
>>>
>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>
>>>
>>>
>>> ________________________________From: Benedikt Ritter
>>> <br...@apache.org>
>>> To: Commons Developers List <de...@commons.apache.org>
>>> 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
>>>> <ol...@oliver-heger.de>:
>>>>
>>>>
>>>>
>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>
>>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by Gilles <gi...@harfang.homelinux.org>.
Hello.
On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
> Hi Bruno,
>
> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>> 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.
Is it a good idea to use deprecated classes[1] in new code?
Regards,
Gilles
[1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>>
>>
>> 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
>
> agreed. This seems to be the best what we can do.
>
> Oliver
>
>>
>>
>> [1] https://github.com/apache/commons-lang/pull/275
>>
>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>
>>
>>
>> ________________________________From: Benedikt Ritter
>> <br...@apache.org>
>> To: Commons Developers List <de...@commons.apache.org>
>> 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
>>> <ol...@oliver-heger.de>:
>>>
>>>
>>>
>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by Oliver Heger <ol...@oliver-heger.de>.
Hi Bruno,
Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
> 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
agreed. This seems to be the best what we can do.
Oliver
>
>
> [1] https://github.com/apache/commons-lang/pull/275
>
> [2] https://issues.apache.org/jira/browse/LANG-1339
>
>
>
> ________________________________From: Benedikt Ritter <br...@apache.org>
> To: Commons Developers List <de...@commons.apache.org>
> 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 <ol...@oliver-heger.de>:
>>
>>
>>
>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Java 9 problems because of dependencies to java.desktop
(Was: Re: [LANG] Thoughts about Lang 4.0)
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
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 <br...@apache.org>
To: Commons Developers List <de...@commons.apache.org>
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 <ol...@oliver-heger.de>:
>
>
>
> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[LANG] Java 9 problems because of dependencies to java.desktop (Was:
Re: [LANG] Thoughts about Lang 4.0)
Posted by Benedikt Ritter <br...@apache.org>.
> Am 25.05.2017 um 18:23 schrieb Oliver Heger <ol...@oliver-heger.de>:
>
>
>
> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>> On 23 May 2017 at 17:17, sebb <se...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
> On 23 May 2017 at 17:17, sebb <se...@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.
Oliver
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Emmanuel Bourg <eb...@apache.org>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Matt Benson <mb...@apache.org>.
On May 24, 2017 6:56 AM, "Stephen Colebourne" <sc...@joda.org> wrote:
On 23 May 2017 at 17:17, sebb <se...@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
Re: [LANG] Thoughts about Lang 4.0
Posted by Stephen Colebourne <sc...@joda.org>.
On 23 May 2017 at 17:17, sebb <se...@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.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Jörg Schaible <jo...@bpm-inspire.com>.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Benedikt Ritter <br...@apache.org>.
Why does every discussion at commons become a discussion about jar hell?
> Am 23.05.2017 um 12:17 schrieb sebb <se...@gmail.com>:
>
> On 23 May 2017 at 16:42, Stephen Colebourne <scolebourne@joda.org <ma...@joda.org>> wrote:
>> On 23 May 2017 at 16:07, sebb <sebbaz@gmail.com <ma...@gmail.com>> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: [LANG] Thoughts about Lang 4.0
Posted by sebb <se...@gmail.com>.
On 23 May 2017 at 16:42, Stephen Colebourne <sc...@joda.org> wrote:
> On 23 May 2017 at 16:07, sebb <se...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Stephen Colebourne <sc...@joda.org>.
On 23 May 2017 at 16:07, sebb <se...@gmail.com> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by sebb <se...@gmail.com>.
On 23 May 2017 at 16:22, Matt Sicker <bo...@gmail.com> 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 <se...@gmail.com> wrote:
>
>> On 23 May 2017 at 12:18, Stephen Colebourne <sc...@joda.org> wrote:
>> > On 23 May 2017 at 11:54, sebb <se...@gmail.com> 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: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Matt Sicker <bo...@gmail.com>.
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 <se...@gmail.com> wrote:
> On 23 May 2017 at 12:18, Stephen Colebourne <sc...@joda.org> wrote:
> > On 23 May 2017 at 11:54, sebb <se...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [LANG] Thoughts about Lang 4.0
Posted by sebb <se...@gmail.com>.
On 23 May 2017 at 12:18, Stephen Colebourne <sc...@joda.org> wrote:
> On 23 May 2017 at 11:54, sebb <se...@gmail.com> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Stephen Colebourne <sc...@joda.org>.
On 23 May 2017 at 11:54, sebb <se...@gmail.com> 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.
I will note that the JDK is removing methods due to exactly the same
issue - modular Java is quite disruptive..
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
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".
Options that remove the methods:
3) Make a backwards incompatible change to remove the bad methods in
v3.7 (no package name change)
4) Make a backwards incompatible change to remove the bad methods in
v4.0 (no package name change)
5) Make a backwards incompatible change to remove the bad methods in
v4.0 (with package name change)
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by sebb <se...@gmail.com>.
On 23 May 2017 at 11:05, Stephen Colebourne <sc...@joda.org> wrote:
> On 22 May 2017 at 00:56, Benedikt Ritter <br...@apache.org> wrote:
>> I think the time has come to start thinking about Lang 4.0.
>
> As I outlined in another thread, Lang 3.5 uses PropertyChangeListener,
> which in module terms pulls in the whole of Swing and AWT. For a
> library like [lang] that is a bad thing and should really be fixed.
>
> 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.
> Yes, the versioning a bit of a mess, but you are where you are.
>
> More broadly, it needs to be established if a lang release for Java 8
> is needed? What would it enable? Would a new commons project be a
> better place for them (ie. a new [core] or [eight] project)?
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Stephen Colebourne <sc...@joda.org>.
On 22 May 2017 at 00:56, Benedikt Ritter <br...@apache.org> wrote:
> I think the time has come to start thinking about Lang 4.0.
As I outlined in another thread, Lang 3.5 uses PropertyChangeListener,
which in module terms pulls in the whole of Swing and AWT. For a
library like [lang] that is a bad thing and should really be fixed.
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. Yes, the versioning a bit of a mess, but you are where
you are.
More broadly, it needs to be established if a lang release for Java 8
is needed? What would it enable? Would a new commons project be a
better place for them (ie. a new [core] or [eight] project)?
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 23/05/2017 à 11:13, Jochen Wiedmann a écrit :
> IMO, c-lang is running well, as it is.
+1
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 23 May 2017 15:33:39 +0200, Jochen Wiedmann wrote:
> On Tue, May 23, 2017 at 12:19 PM, Gilles
> <gi...@harfang.homelinux.org> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, May 23, 2017 at 12:19 PM, Gilles <gi...@harfang.homelinux.org> 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.)
Jochen
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 23 May 2017 11:13:21 +0200, Jochen Wiedmann wrote:
> On Mon, May 22, 2017 at 1:47 PM, Rob Tompkins <ch...@gmail.com>
> wrote:
>
>>> - commons-system: a library focused on working with system
>>> properties and detection of the operation system, system’s
>>> architecture and Java version
>>> - commons-concurrent: a library providing additional abstractions
>>> and implementations for the java.util.concurrent package
>>> - commons-reflect: a library which helps working with reflection
>>> (where is the line to beanutils here?)
>>> - commons-date: a library which helps working with the
>>> java.util.Date and java.util.Calendar APIs
>
> I am -0 to -1 regarding the introduction of new components. I'd
> rather
> see us redefine the purpose of commons-lang. The experience of
> commons-math has demonstrated, IMO, that such new components will
> most
> likely increase the noise without an associated increase of the
> output.
Can you be explicit with what counts as "noise"?
If "output" is total number of lines of code, then you are right; I'm
trying to reduce it for "Commons Math", in the hope that the project
will be better off on all other counts besides plain size.
> IMO, c-lang is running well, as it is.
Sure; hence the talk about fixing its dependency on Swing (IIUC)...
Finer-grained and modular components are much easier to manage. Its
an improvement, especially for users who need to control their
dependencies.
Regards,
Gilles
>
> Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Stephen Colebourne <sc...@joda.org>.
On 23 May 2017 at 10:13, Jochen Wiedmann <jo...@gmail.com> wrote:
> I am -0 to -1 regarding the introduction of new components. I'd rather
> see us redefine the purpose of commons-lang. The experience of
> commons-math has demonstrated, IMO, that such new components will most
> likely increase the noise without an associated increase of the
> output.
>
> IMO, c-lang is running well, as it is.
I'm not personally convinced that smaller components solves anything.
It gives end users more dependencies to manage, with more potential
for clashes. Plus, no-one should be adding a dependency for just a
couple of simple methods - thus [lang] needs to be a certain size to
have enough useful methods to justify itself. The "competition" is
Guava, and that is also a decent size library.
Looking to Java 10 and beyond, we might see a way to have one artifact
(jar file) contain multiple modules, allowing end-users to depend on
parts of [lang] package by package. In such a scenario, it would
actually be better to lump more into a single jar file, not less.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Mon, May 22, 2017 at 1:47 PM, Rob Tompkins <ch...@gmail.com> wrote:
>> - commons-system: a library focused on working with system properties and detection of the operation system, system’s architecture and Java version
>> - commons-concurrent: a library providing additional abstractions and implementations for the java.util.concurrent package
>> - commons-reflect: a library which helps working with reflection (where is the line to beanutils here?)
>> - commons-date: a library which helps working with the java.util.Date and java.util.Calendar APIs
I am -0 to -1 regarding the introduction of new components. I'd rather
see us redefine the purpose of commons-lang. The experience of
commons-math has demonstrated, IMO, that such new components will most
likely increase the noise without an associated increase of the
output.
IMO, c-lang is running well, as it is.
Jochen
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Matt Sicker <bo...@gmail.com>.
On 22 May 2017 at 14:35, Jan Matèrne (jhm) <ap...@materne.de> wrote:
>
> One benefit of having an ASF commons "tuple library" is .... it's from the
> ASF.
> I am not joking. An ASF library promisses to have a community and a life
> cycle you can
> precognize. In contrast a "simple" github library is just a peace of code.
This is a great point, honestly. I don't like using random tuple util
classes from my dependencies (other than in Scala now since they have it in
their standard library) in any public code (though it's usable in private
methods, etc.). Given a nice enough tuple library, it may be possible to
see it start to replace all the random tuple utils elsewhere.
> I think converter functions between java.util.Date and java.time could be
> helpful.
> Think of "old" modules of your application (maybe 3rd party libs) which
> require the one
> and other parts which require the other.
Like these?
https://docs.oracle.com/javase/8/docs/api/java/util/Date.html#from-java.time.Instant-
https://docs.oracle.com/javase/8/docs/api/java/util/Date.html#toInstant--
--
Matt Sicker <bo...@gmail.com>
AW: [LANG] Thoughts about Lang 4.0
Posted by "Jan Matèrne (jhm)" <ap...@materne.de>.
> For the tuple classes, it would be possible to make an entire tuples
> library. Might be handy to generate code for it as it'd be useful to
> support tuples up to, say, 22 fields (Scala has tuple classes and
> anonymous function classes up to 22 arguments, for example). See <
> https://www.scala-lang.org/api/current/scala/Tuple22.html>.
One benefit of having an ASF commons "tuple library" is .... it's from the ASF.
I am not joking. An ASF library promisses to have a community and a life cycle you can
precognize. In contrast a "simple" github library is just a peace of code.
> If we go to Java 8 as a base line (which would make sense), we don't
> need a commons-date library anymore, though if we did, it would be
> based on the java.time API instead. Not sure which functionality would
> be useful here.
I think converter functions between java.util.Date and java.time could be helpful.
Think of "old" modules of your application (maybe 3rd party libs) which require the one
and other parts which require the other.
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Gary Gregory <ga...@gmail.com>.
Yes, but tuples are generally useful outside of lambdas, well, at least the
size 2 kind.
Gary
On Mon, May 22, 2017 at 11:24 AM, Pascal Schumacher <
pascalschumacher@gmx.net> wrote:
> Am 22.05.2017 um 17:55 schrieb Matt Sicker:
>
>> For the tuple classes, it would be possible to make an entire tuples
>> library. Might be handy to generate code for it as it'd be useful to
>> support tuples up to, say, 22 fields (Scala has tuple classes and
>> anonymous
>> function classes up to 22 arguments, for example). See <
>> https://www.scala-lang.org/api/current/scala/Tuple22.html>.
>>
> Well there are already good Apache 2.0 licensed java libraries for tuples
> and functions, e.g.:
>
> https://github.com/jOOQ/jOOL (up to 16)
>
> https://github.com/vavr-io/vavr (up to 8)
>
> (both of course offer more that just tuples and functions).
>
> Just saying.
>
> Cheers,
> Pascal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: [LANG] Thoughts about Lang 4.0
Posted by Pascal Schumacher <pa...@gmx.net>.
Am 22.05.2017 um 17:55 schrieb Matt Sicker:
> For the tuple classes, it would be possible to make an entire tuples
> library. Might be handy to generate code for it as it'd be useful to
> support tuples up to, say, 22 fields (Scala has tuple classes and anonymous
> function classes up to 22 arguments, for example). See <
> https://www.scala-lang.org/api/current/scala/Tuple22.html>.
Well there are already good Apache 2.0 licensed java libraries for
tuples and functions, e.g.:
https://github.com/jOOQ/jOOL (up to 16)
https://github.com/vavr-io/vavr (up to 8)
(both of course offer more that just tuples and functions).
Just saying.
Cheers,
Pascal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, May 22, 2017 at 8:55 AM, Matt Sicker <bo...@gmail.com> wrote:
> For the tuple classes, it would be possible to make an entire tuples
> library. Might be handy to generate code for it as it'd be useful to
> support tuples up to, say, 22 fields (Scala has tuple classes and anonymous
> function classes up to 22 arguments, for example). See <
> https://www.scala-lang.org/api/current/scala/Tuple22.html>.
>
> If we go to Java 8 as a base line (which would make sense), we don't need a
> commons-date library anymore, though if we did, it would be based on the
> java.time API instead. Not sure which functionality would be useful here.
>
+1 to Java 8 and covering java.time.
It seems like the 3.x line will be alive for a long time and that we might
want to stick to bug fixes only there once 4.0 is out, depending on who
might volunteer to RM.
Gary
>
> For commons-concurrent and -system, I like the ideas. As for -reflection
> versus -beanutils, perhaps some exploration toward merging the two could be
> made?
>
> On 22 May 2017 at 06:47, Rob Tompkins <ch...@gmail.com> wrote:
>
> >
> > > On May 21, 2017, at 7:56 PM, Benedikt Ritter <br...@apache.org>
> wrote:
> > >
> > > Hi,
> > >
> > > I think the time has come to start thinking about Lang 4.0. A new major
> > release is a chance to clean up stuff and get rid of APIs we don’t need
> > anymore/don’t want to maintain anymore. Lang has become rather large.
> It’s
> > description still is
> > >
> > > „Lang provides a host of helper utilities for the java.lang API […]"
> > >
> > > When I look at Lang I see a lot of stuff which has nothing to do with
> > the java.lang package. I think our aim for 4.0 should be to get back to
> > that again. I like the approach we took with math. Splitting a large
> > package down into smaller individual components is a good idea. So my
> > proposal is to split out more new components from Lang like we did with
> > commons-text and deprecate that stuff in lang. Then we can start with
> Lang
> > 4.0 and remove all that stuff.
> > >
> > > Here are some components I think we could extract from Lang:
> > >
> > > - commons-system: a library focused on working with system properties
> > and detection of the operation system, system’s architecture and Java
> > version
> > > - commons-concurrent: a library providing additional abstractions and
> > implementations for the java.util.concurrent package
> > > - commons-reflect: a library which helps working with reflection (where
> > is the line to beanutils here?)
> > > - commons-date: a library which helps working with the java.util.Date
> > and java.util.Calendar APIs
> > >
> > > Furthermore I’d remove the o.a.c.lang3.event package. The stuff in
> > o.a.c.lang3.math could maybe find a new home in one of the commons-math
> > components.
> > >
> > > The o.a.c.lang3.builder package fits into Lang 4.0 but I’d rename it to
> > o.a.c.lang4.object (if that’s possible). Further more I’d remove the
> > Builder interface.
> > >
> > > The o.a.c.lang3.mutable and o.a.c.lang3.tuple package as well as the
> > o.a.c.lang3.exception package can stay as they are.
> > >
> > > WDYT?
> >
> > The only thing that occurs to me is that we should make sure that Java 9
> > is fully in general availability before releasing 4.0.
> >
> > > Benedikt
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: [LANG] Thoughts about Lang 4.0
Posted by Matt Sicker <bo...@gmail.com>.
For the tuple classes, it would be possible to make an entire tuples
library. Might be handy to generate code for it as it'd be useful to
support tuples up to, say, 22 fields (Scala has tuple classes and anonymous
function classes up to 22 arguments, for example). See <
https://www.scala-lang.org/api/current/scala/Tuple22.html>.
If we go to Java 8 as a base line (which would make sense), we don't need a
commons-date library anymore, though if we did, it would be based on the
java.time API instead. Not sure which functionality would be useful here.
For commons-concurrent and -system, I like the ideas. As for -reflection
versus -beanutils, perhaps some exploration toward merging the two could be
made?
On 22 May 2017 at 06:47, Rob Tompkins <ch...@gmail.com> wrote:
>
> > On May 21, 2017, at 7:56 PM, Benedikt Ritter <br...@apache.org> wrote:
> >
> > Hi,
> >
> > I think the time has come to start thinking about Lang 4.0. A new major
> release is a chance to clean up stuff and get rid of APIs we don’t need
> anymore/don’t want to maintain anymore. Lang has become rather large. It’s
> description still is
> >
> > „Lang provides a host of helper utilities for the java.lang API […]"
> >
> > When I look at Lang I see a lot of stuff which has nothing to do with
> the java.lang package. I think our aim for 4.0 should be to get back to
> that again. I like the approach we took with math. Splitting a large
> package down into smaller individual components is a good idea. So my
> proposal is to split out more new components from Lang like we did with
> commons-text and deprecate that stuff in lang. Then we can start with Lang
> 4.0 and remove all that stuff.
> >
> > Here are some components I think we could extract from Lang:
> >
> > - commons-system: a library focused on working with system properties
> and detection of the operation system, system’s architecture and Java
> version
> > - commons-concurrent: a library providing additional abstractions and
> implementations for the java.util.concurrent package
> > - commons-reflect: a library which helps working with reflection (where
> is the line to beanutils here?)
> > - commons-date: a library which helps working with the java.util.Date
> and java.util.Calendar APIs
> >
> > Furthermore I’d remove the o.a.c.lang3.event package. The stuff in
> o.a.c.lang3.math could maybe find a new home in one of the commons-math
> components.
> >
> > The o.a.c.lang3.builder package fits into Lang 4.0 but I’d rename it to
> o.a.c.lang4.object (if that’s possible). Further more I’d remove the
> Builder interface.
> >
> > The o.a.c.lang3.mutable and o.a.c.lang3.tuple package as well as the
> o.a.c.lang3.exception package can stay as they are.
> >
> > WDYT?
>
> The only thing that occurs to me is that we should make sure that Java 9
> is fully in general availability before releasing 4.0.
>
> > Benedikt
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [LANG] Thoughts about Lang 4.0
Posted by Rob Tompkins <ch...@gmail.com>.
> On May 21, 2017, at 7:56 PM, Benedikt Ritter <br...@apache.org> wrote:
>
> Hi,
>
> I think the time has come to start thinking about Lang 4.0. A new major release is a chance to clean up stuff and get rid of APIs we don’t need anymore/don’t want to maintain anymore. Lang has become rather large. It’s description still is
>
> „Lang provides a host of helper utilities for the java.lang API […]"
>
> When I look at Lang I see a lot of stuff which has nothing to do with the java.lang package. I think our aim for 4.0 should be to get back to that again. I like the approach we took with math. Splitting a large package down into smaller individual components is a good idea. So my proposal is to split out more new components from Lang like we did with commons-text and deprecate that stuff in lang. Then we can start with Lang 4.0 and remove all that stuff.
>
> Here are some components I think we could extract from Lang:
>
> - commons-system: a library focused on working with system properties and detection of the operation system, system’s architecture and Java version
> - commons-concurrent: a library providing additional abstractions and implementations for the java.util.concurrent package
> - commons-reflect: a library which helps working with reflection (where is the line to beanutils here?)
> - commons-date: a library which helps working with the java.util.Date and java.util.Calendar APIs
>
> Furthermore I’d remove the o.a.c.lang3.event package. The stuff in o.a.c.lang3.math could maybe find a new home in one of the commons-math components.
>
> The o.a.c.lang3.builder package fits into Lang 4.0 but I’d rename it to o.a.c.lang4.object (if that’s possible). Further more I’d remove the Builder interface.
>
> The o.a.c.lang3.mutable and o.a.c.lang3.tuple package as well as the o.a.c.lang3.exception package can stay as they are.
>
> WDYT?
The only thing that occurs to me is that we should make sure that Java 9 is fully in general availability before releasing 4.0.
> Benedikt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts about Lang 4.0
Posted by Gary Gregory <ga...@gmail.com>.
One thought for a multi module 4.0 would be to cover Java 8.
Gary
On May 21, 2017 4:57 PM, "Benedikt Ritter" <br...@apache.org> wrote:
Hi,
I think the time has come to start thinking about Lang 4.0. A new major
release is a chance to clean up stuff and get rid of APIs we don’t need
anymore/don’t want to maintain anymore. Lang has become rather large. It’s
description still is
„Lang provides a host of helper utilities for the java.lang API […]"
When I look at Lang I see a lot of stuff which has nothing to do with the
java.lang package. I think our aim for 4.0 should be to get back to that
again. I like the approach we took with math. Splitting a large package
down into smaller individual components is a good idea. So my proposal is
to split out more new components from Lang like we did with commons-text
and deprecate that stuff in lang. Then we can start with Lang 4.0 and
remove all that stuff.
Here are some components I think we could extract from Lang:
- commons-system: a library focused on working with system properties and
detection of the operation system, system’s architecture and Java version
- commons-concurrent: a library providing additional abstractions and
implementations for the java.util.concurrent package
- commons-reflect: a library which helps working with reflection (where is
the line to beanutils here?)
- commons-date: a library which helps working with the java.util.Date and
java.util.Calendar APIs
Furthermore I’d remove the o.a.c.lang3.event package. The stuff in
o.a.c.lang3.math could maybe find a new home in one of the commons-math
components.
The o.a.c.lang3.builder package fits into Lang 4.0 but I’d rename it to
o.a.c.lang4.object (if that’s possible). Further more I’d remove the
Builder interface.
The o.a.c.lang3.mutable and o.a.c.lang3.tuple package as well as the
o.a.c.lang3.exception package can stay as they are.
WDYT?
Benedikt