commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita" <brunodepau...@yahoo.com.br.INVALID>
Subject Re: [LANG] Java 9 problems because of dependencies to java.desktop
Date Thu, 19 Jul 2018 23:09:46 GMT
>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 <gilles@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.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



   
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message