>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 <gil...@harfang.homelinux.org>
To: dev@commons.apache.org
Sent: Friday, 20 July 2018 11:05 AM
Subject: Re: [LANG] Java 9 problems because of dependencies to java.desktop
Hello.
On Mon, 16 Jul 2018 21:30:00 +0000 (UTC), Bruno P. Kinoshita wrote:
>>What about introducing our own state listener interface? The original
>>interface from the beans package was used just for convenience
>> because
>>it already existed. But it would of course be possible to have a
>> simple
>>functional interface to notify listeners about state changes.
> Hmmm, that's an option as well.
> Looks like they had the beans interface which we used, then later we
> had the java.util.Observable for a while, and now they are suggesting
> users to move to the beans interface, as one of the alternatives.
> As some Java 9 users possibly wouldn't want to import the java.beans
> module, perhaps having this new interface could be an interesting
> alternative.
> I believe we would have to
> [ ] decide whether to introduce an interface similar to
> PropertyListener, or to Observable[ ] if the backward compatibility
> changed, we must deprecate the existing classes
> [ ] release a new version of lang with this new interface and the
> updated circuit breakers[ ] and either delete the deprecated classes
> or leave it until for some more releases
> I wonder what others think about this option?
What is the replacement for Observer/Observable recommended by
the JDK developers?
Regards,
Gilles
> Cheers
> Bruno
>
>
> From: Oliver Heger <oliver.he...@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 <scolebou...@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 <gil...@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
>>>>> <brit...@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.he...@oliver-heger.de>:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 24.05.2017 um 13:55 schrieb Stephen Colebourne:
>>>>>>>
>>>>>>> On 23 May 2017 at 17:17, sebb <seb...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
