[LANG] Thoughts about Lang 4.0

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

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

garydgregory
So the dependency on desktop is declared as optional but it still exists?

Gary

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

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

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

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

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

Reply | Threaded
Open this post in threaded view
|

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

jodastephen
On 10 June 2018 at 00:02, Bruno P. Kinoshita
<[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

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

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

Reply | Threaded
Open this post in threaded view
|

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

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


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

Reply | Threaded
Open this post in threaded view
|

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

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

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

Reply | Threaded
Open this post in threaded view
|

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

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

>

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

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

Reply | Threaded
Open this post in threaded view
|

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

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

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

Reply | Threaded
Open this post in threaded view
|

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

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

>

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

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

Reply | Threaded
Open this post in threaded view
|

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

Oliver Heger-3


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

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

Reply | Threaded
Open this post in threaded view
|

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

Pascal Schumacher
In reply to this post by Bruno P. Kinoshita-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

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

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



   
Reply | Threaded
Open this post in threaded view
|

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

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

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



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

Reply | Threaded
Open this post in threaded view
|

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

Oliver Heger-3


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

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

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Java 9 problems because of dependencies to java.desktop

Gilles Sadowski
In reply to this post by Bruno P. Kinoshita-3
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 <[hidden email]>
>  To: [hidden email]
>  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 <[hidden email]>
>> To: Commons Developers List <[hidden email]>
>> 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 <[hidden email]>
>> 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
>>>>> <[hidden email]>
>>>>> To: Commons Developers List <[hidden email]>
>>>>> Sent: Monday, 5 June 2017 10:49 PM
>>>>> Subject: [LANG] Java 9 problems because of dependencies to
>>>>> java.desktop
>>>>> (Was: Re: [LANG] Thoughts about Lang 4.0)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Am 25.05.2017 um 18:23 schrieb Oliver Heger
>>>>>> <[hidden email]>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>>
>>>>>>> On 23 May 2017 at 17:17, sebb <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> Yes, the
>>>>>>>>> code compiles and both can be on the classpath, but it is a
>>>>>>>>> pain to
>>>>>>>>> use, just a different kind of hell.
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't see what the problem is here.
>>>>>>>
>>>>>>>
>>>>>>> Library A that depends on lang3 returns a Pair.
>>>>>>> Library B that depends on lang4 takes a Pair.
>>>>>>> Application cannot pass Pair from A to the B without
>>>>>>> conversion.
>>>>>>>
>>>>>>> My point is that it is possible to over-worry about jar hell.
>>>>>>> Joda-Time removed some methods when it went from v1.x to v2.x,
>>>>>>> but
>>>>>>> didn't change package name or maven co-ordinates. It was far
>>>>>>> more
>>>>>>> important that end-users didn't have two different LocalDate
>>>>>>> classes
>>>>>>> (a problem that couldn't be avoided when moving to Java 8).
>>>>>>> I've never
>>>>>>> seen any feedback about the incompatibility causing jar hell.
>>>>>>>
>>>>>>> The same is true here. It is vital to think properly about
>>>>>>> which is
>>>>>>> the worse choice, not just assume that jar hell must always be
>>>>>>> avoided.
>>>>>>>
>>>>>>> I remain completely unconvinced that removing these two
>>>>>>> problematic
>>>>>>> methods justifies the lang4 package name, forcing end-users to
>>>>>>> have
>>>>>>> three copies of the library on the classpath. It should need
>>>>>>> much,
>>>>>>> much more to justify lang4 package name. In fact I've yet to
>>>>>>> hear
>>>>>>> anything else much in this thread that justifies a major
>>>>>>> release.
>>>>>>
>>>>>>
>>>>>> I also think that a new major release just to fix this problem
>>>>>> would be
>>>>>> overkill and cause clients even more trouble.
>>>>>>
>>>>>> Would the following approach work as a compromise:
>>>>>>
>>>>>> - [lang] declares an optional dependency to the desktop module.
>>>>>> - All affected classes (AbstractCircuitBreaker and its two sub
>>>>>> classes)
>>>>>> are marked as deprecated.
>>>>>> - Copies are created from the original classes with slightly
>>>>>> changed
>>>>>> names or in a new package (tbd). These copies use a new change
>>>>>> listener
>>>>>> mechanism.
>>>>>>
>>>>>> IIUC, the resulting [lang] module can now be used without the
>>>>>> dependency
>>>>>> to desktop when the new classes are used. The dependency will
>>>>>> only be
>>>>>> needed for the deprecated versions.
>>>>>
>>>>>
>>>>> Let’s do it like this. Sounds like the right way to me.
>>>>>
>>>>> Benedikt
>>>>>
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>>>
>>>>>>> Stephen
>>>>>>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Java 9 problems because of dependencies to java.desktop

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


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



   
Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Java 9 problems because of dependencies to java.desktop

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

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

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Java 9 problems because of dependencies to java.desktop

Gilles Sadowski
Hi.

On Fri, 20 Jul 2018 09:47:21 +0100, sebb wrote:

> On 20 July 2018 at 00:09, Bruno P. Kinoshita
> <[hidden email]> 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 <[hidden email]>
>>  To: [hidden email]
>>  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 <[hidden email]>
>>>  To: [hidden email]
>>>  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 <[hidden email]>
>>>> To: Commons Developers List <[hidden email]>
>>>> 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 <[hidden email]>
>>>> 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
>>>>>>> <[hidden email]>
>>>>>>> To: Commons Developers List <[hidden email]>
>>>>>>> Sent: Monday, 5 June 2017 10:49 PM
>>>>>>> Subject: [LANG] Java 9 problems because of dependencies to
>>>>>>> java.desktop
>>>>>>> (Was: Re: [LANG] Thoughts about Lang 4.0)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Am 25.05.2017 um 18:23 schrieb Oliver Heger
>>>>>>>> <[hidden email]>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>>>>
>>>>>>>>> On 23 May 2017 at 17:17, sebb <[hidden email]> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Yes, the
>>>>>>>>>>> code compiles and both can be on the classpath, but it is a
>>>>>>>>>>> pain to
>>>>>>>>>>> use, just a different kind of hell.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I don't see what the problem is here.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Library A that depends on lang3 returns a Pair.
>>>>>>>>> Library B that depends on lang4 takes a Pair.
>>>>>>>>> Application cannot pass Pair from A to the B without
>>>>>>>>> conversion.
>>>>>>>>>
>>>>>>>>> My point is that it is possible to over-worry about jar hell.
>>>>>>>>> Joda-Time removed some methods when it went from v1.x to
>>>>>>>>> v2.x,
>>>>>>>>> but
>>>>>>>>> didn't change package name or maven co-ordinates. It was far
>>>>>>>>> more
>>>>>>>>> important that end-users didn't have two different LocalDate
>>>>>>>>> classes
>>>>>>>>> (a problem that couldn't be avoided when moving to Java 8).
>>>>>>>>> I've never
>>>>>>>>> seen any feedback about the incompatibility causing jar hell.
>>>>>>>>>
>>>>>>>>> The same is true here. It is vital to think properly about
>>>>>>>>> which is
>>>>>>>>> the worse choice, not just assume that jar hell must always
>>>>>>>>> be
>>>>>>>>> avoided.
>>>>>>>>>
>>>>>>>>> I remain completely unconvinced that removing these two
>>>>>>>>> problematic
>>>>>>>>> methods justifies the lang4 package name, forcing end-users
>>>>>>>>> to
>>>>>>>>> have
>>>>>>>>> three copies of the library on the classpath. It should need
>>>>>>>>> much,
>>>>>>>>> much more to justify lang4 package name. In fact I've yet to
>>>>>>>>> hear
>>>>>>>>> anything else much in this thread that justifies a major
>>>>>>>>> release.
>>>>>>>>
>>>>>>>>
>>>>>>>> I also think that a new major release just to fix this problem
>>>>>>>> would be
>>>>>>>> overkill and cause clients even more trouble.
>>>>>>>>
>>>>>>>> Would the following approach work as a compromise:
>>>>>>>>
>>>>>>>> - [lang] declares an optional dependency to the desktop
>>>>>>>> module.
>>>>>>>> - All affected classes (AbstractCircuitBreaker and its two sub
>>>>>>>> classes)
>>>>>>>> are marked as deprecated.
>>>>>>>> - Copies are created from the original classes with slightly
>>>>>>>> changed
>>>>>>>> names or in a new package (tbd). These copies use a new change
>>>>>>>> listener
>>>>>>>> mechanism.
>>>>>>>>
>>>>>>>> IIUC, the resulting [lang] module can now be used without the
>>>>>>>> dependency
>>>>>>>> to desktop when the new classes are used. The dependency will
>>>>>>>> only be
>>>>>>>> needed for the deprecated versions.
>>>>>>>
>>>>>>>
>>>>>>> Let’s do it like this. Sounds like the right way to me.
>>>>>>>
>>>>>>> Benedikt
>>>>>>>
>>>>>>>>
>>>>>>>> Oliver
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Stephen
>>>>>>>>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [LANG] Java 9 problems because of dependencies to java.desktop

Matt Sicker
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 <[hidden email]> wrote:

> Hi.
>
> On Fri, 20 Jul 2018 09:47:21 +0100, sebb wrote:
> > On 20 July 2018 at 00:09, Bruno P. Kinoshita
> > <[hidden email]> 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 <[hidden email]>
> >>  To: [hidden email]
> >>  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 <[hidden email]>
> >>>  To: [hidden email]
> >>>  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 <[hidden email]>
> >>>> To: Commons Developers List <[hidden email]>
> >>>> 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 <[hidden email]>
> >>>> 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
> >>>>>>> <[hidden email]>
> >>>>>>> To: Commons Developers List <[hidden email]>
> >>>>>>> Sent: Monday, 5 June 2017 10:49 PM
> >>>>>>> Subject: [LANG] Java 9 problems because of dependencies to
> >>>>>>> java.desktop
> >>>>>>> (Was: Re: [LANG] Thoughts about Lang 4.0)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Am 25.05.2017 um 18:23 schrieb Oliver Heger
> >>>>>>>> <[hidden email]>:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
> >>>>>>>>>
> >>>>>>>>> On 23 May 2017 at 17:17, sebb <[hidden email]> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Yes, the
> >>>>>>>>>>> code compiles and both can be on the classpath, but it is a
> >>>>>>>>>>> pain to
> >>>>>>>>>>> use, just a different kind of hell.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I don't see what the problem is here.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Library A that depends on lang3 returns a Pair.
> >>>>>>>>> Library B that depends on lang4 takes a Pair.
> >>>>>>>>> Application cannot pass Pair from A to the B without
> >>>>>>>>> conversion.
> >>>>>>>>>
> >>>>>>>>> My point is that it is possible to over-worry about jar hell.
> >>>>>>>>> Joda-Time removed some methods when it went from v1.x to
> >>>>>>>>> v2.x,
> >>>>>>>>> but
> >>>>>>>>> didn't change package name or maven co-ordinates. It was far
> >>>>>>>>> more
> >>>>>>>>> important that end-users didn't have two different LocalDate
> >>>>>>>>> classes
> >>>>>>>>> (a problem that couldn't be avoided when moving to Java 8).
> >>>>>>>>> I've never
> >>>>>>>>> seen any feedback about the incompatibility causing jar hell.
> >>>>>>>>>
> >>>>>>>>> The same is true here. It is vital to think properly about
> >>>>>>>>> which is
> >>>>>>>>> the worse choice, not just assume that jar hell must always
> >>>>>>>>> be
> >>>>>>>>> avoided.
> >>>>>>>>>
> >>>>>>>>> I remain completely unconvinced that removing these two
> >>>>>>>>> problematic
> >>>>>>>>> methods justifies the lang4 package name, forcing end-users
> >>>>>>>>> to
> >>>>>>>>> have
> >>>>>>>>> three copies of the library on the classpath. It should need
> >>>>>>>>> much,
> >>>>>>>>> much more to justify lang4 package name. In fact I've yet to
> >>>>>>>>> hear
> >>>>>>>>> anything else much in this thread that justifies a major
> >>>>>>>>> release.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I also think that a new major release just to fix this problem
> >>>>>>>> would be
> >>>>>>>> overkill and cause clients even more trouble.
> >>>>>>>>
> >>>>>>>> Would the following approach work as a compromise:
> >>>>>>>>
> >>>>>>>> - [lang] declares an optional dependency to the desktop
> >>>>>>>> module.
> >>>>>>>> - All affected classes (AbstractCircuitBreaker and its two sub
> >>>>>>>> classes)
> >>>>>>>> are marked as deprecated.
> >>>>>>>> - Copies are created from the original classes with slightly
> >>>>>>>> changed
> >>>>>>>> names or in a new package (tbd). These copies use a new change
> >>>>>>>> listener
> >>>>>>>> mechanism.
> >>>>>>>>
> >>>>>>>> IIUC, the resulting [lang] module can now be used without the
> >>>>>>>> dependency
> >>>>>>>> to desktop when the new classes are used. The dependency will
> >>>>>>>> only be
> >>>>>>>> needed for the deprecated versions.
> >>>>>>>
> >>>>>>>
> >>>>>>> Let’s do it like this. Sounds like the right way to me.
> >>>>>>>
> >>>>>>> Benedikt
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Oliver
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Stephen
> >>>>>>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Matt Sicker <[hidden email]>
123