commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pascal Schumacher <pascalschumac...@gmx.net>
Subject Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re: [LANG] Thoughts about Lang 4.0)
Date Tue, 17 Jul 2018 17:11:10 GMT
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 <oliver.heger@oliver-heger.de>
>   To: dev@commons.apache.org
>   Sent: Tuesday, 17 July 2018 4:13 AM
>   Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was: Re:
[LANG] Thoughts about Lang 4.0)
>     
>
>
> Am 16.07.2018 um 13:40 schrieb Bruno P. Kinoshita:
>> Saw some recent activity around lang 3.8, and remembered about this issue, and then
looked for this thread.
>>
>> Gilles' point is really good! Here's the Java 9 docs with the deprecation warning,
copied below as well https://docs.oracle.com/javase/9/docs/api/index.html?java/util/Observable.html
>>
>>
>> "This class and the Observer interface have been deprecated. The event model supported
by Observer and Observable is quite limited, the order of notifications delivered by Observable
is unspecified, and state changes are not in one-for-one correspondence with notifications.
For a richer event model, consider using the java.beans package.  For reliable and ordered
messaging among threads, consider using one of the concurrent data structures in the java.util.concurrent
package. For reactive streams style programming, see the Flow API."
>>
>>
>>
>> So I guess the best we can do right now is add the @deprecated annotations, with
an explanation in the javadocs. And also add a note about it in the release notes.
>>
>> Does that sound like a good plan? Adding a link to this thread in the pull request
as well.
>>
> What about introducing our own state listener interface? The original
> interface from the beans package was used just for convenience because
> it already existed. But it would of course be possible to have a simple
> functional interface to notify listeners about state changes.
>
> Oliver
>
>> Cheers
>> Bruno
>>
>>
>>
>>
>> ________________________________
>> From: Stephen Colebourne <scolebourne@joda.org>
>> To: Commons Developers List <dev@commons.apache.org>
>> Sent: Monday, 11 June 2018 9:26 AM
>> Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop (Was:
Re: [LANG] Thoughts about Lang 4.0)
>>
>>
>>
>> Good spot. I think that means [lang] would have to have its own copy
>> of the JDK interfaces. or just deprecate the functionality without
>> replacement.
>> Stephen
>>
>> On 10 June 2018 at 22:11, Gilles <gilles@harfang.homelinux.org> wrote:
>>> Hello.
>>>
>>> On Sun, 10 Jun 2018 21:34:49 +0200, Oliver Heger wrote:
>>>> Hi Bruno,
>>>>
>>>> Am 10.06.2018 um 00:52 schrieb Bruno P. Kinoshita:
>>>>> Hi all,
>>>>>
>>>>> There is a patch [1] for LANG-1339 [2] that I would like to merge. The
>>>>> discussion around this issue can be found in the rest of this e-mail
thread.
>>>>>
>>>>> The patch basically deprecates the existing classes that depend on
>>>>> java.desktop, and provide alternative implementations. The previous classes
>>>>> used java.desktop classes for the PropertyChangeListener. And the
>>>>> alternative ones instead use Java 7's java.util.Observer.
>>>
>>> Is it a good idea to use deprecated classes[1] in new code?
>>>
>>> Regards,
>>> Gilles
>>>
>>> [1] https://docs.oracle.com/javase/9/docs/api/java/util/Observable.html
>>>
>>>
>>>>>
>>>>> This will make it easier to provide [lang] as java 9, without requiring
>>>>> users to include a dependency to java.desktop.
>>>>> Planning to merge it during the next week if there are no objections
>>>>> here.
>>>>>
>>>>> Thanks,
>>>>> Bruno
>>>>
>>>> agreed. This seems to be the best what we can do.
>>>>
>>>> Oliver
>>>>
>>>>>
>>>>> [1] https://github.com/apache/commons-lang/pull/275
>>>>>
>>>>> [2] https://issues.apache.org/jira/browse/LANG-1339
>>>>>
>>>>>
>>>>>
>>>>> ________________________________From: Benedikt Ritter
>>>>> <britter@apache.org>
>>>>> To: Commons Developers List <dev@commons.apache.org>
>>>>> Sent: Monday, 5 June 2017 10:49 PM
>>>>> Subject: [LANG] Java 9 problems because of dependencies to java.desktop
>>>>> (Was: Re: [LANG] Thoughts about Lang 4.0)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Am 25.05.2017 um 18:23 schrieb Oliver Heger
>>>>>> <oliver.heger@oliver-heger.de>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>> On 23 May 2017 at 17:17, sebb <sebbaz@gmail.com> wrote:
>>>>>>>>> Yes, the
>>>>>>>>> code compiles and both can be on the classpath, but it
is a pain to
>>>>>>>>> use, just a different kind of hell.
>>>>>>>>
>>>>>>>> I don't see what the problem is here.
>>>>>>>
>>>>>>> Library A that depends on lang3 returns a Pair.
>>>>>>> Library B that depends on lang4 takes a Pair.
>>>>>>> Application cannot pass Pair from A to the B without conversion.
>>>>>>>
>>>>>>> My point is that it is possible to over-worry about jar hell.
>>>>>>> Joda-Time removed some methods when it went from v1.x to v2.x,
but
>>>>>>> didn't change package name or maven co-ordinates. It was far
more
>>>>>>> important that end-users didn't have two different LocalDate
classes
>>>>>>> (a problem that couldn't be avoided when moving to Java 8). I've
never
>>>>>>> seen any feedback about the incompatibility causing jar hell.
>>>>>>>
>>>>>>> The same is true here. It is vital to think properly about which
is
>>>>>>> the worse choice, not just assume that jar hell must always be
>>>>>>> avoided.
>>>>>>>
>>>>>>> I remain completely unconvinced that removing these two problematic
>>>>>>> methods justifies the lang4 package name, forcing end-users to
have
>>>>>>> three copies of the library on the classpath. It should need
much,
>>>>>>> much more to justify lang4 package name. In fact I've yet to
hear
>>>>>>> anything else much in this thread that justifies a major release.
>>>>>>
>>>>>> I also think that a new major release just to fix this problem would
be
>>>>>> overkill and cause clients even more trouble.
>>>>>>
>>>>>> Would the following approach work as a compromise:
>>>>>>
>>>>>> - [lang] declares an optional dependency to the desktop module.
>>>>>> - All affected classes (AbstractCircuitBreaker and its two sub classes)
>>>>>> are marked as deprecated.
>>>>>> - Copies are created from the original classes with slightly changed
>>>>>> names or in a new package (tbd). These copies use a new change listener
>>>>>> mechanism.
>>>>>>
>>>>>> IIUC, the resulting [lang] module can now be used without the dependency
>>>>>> to desktop when the new classes are used. The dependency will only
be
>>>>>> needed for the deprecated versions.
>>>>>
>>>>> Let’s do it like this. Sounds like the right way to me.
>>>>>
>>>>> Benedikt
>>>>>
>>>>>> Oliver
>>>>>>
>>>>>>> Stephen
>>>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>     



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


Mime
View raw message