commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [LANG] Java 9 problems because of dependencies to java.desktop
Date Fri, 20 Jul 2018 08:47:21 GMT
On 20 July 2018 at 00:09, Bruno P. Kinoshita
<brunodepaulak@yahoo.com.br.invalid> wrote:
>>What is the replacement for Observer/Observable recommended by
>>the JDK developers?
> I believe they suggest to use the PropertyListener which we have right now, but are in
the java.beans module I think.
> Alternatively, they also suggest in the javadocs to look into the java.util.concurrent
package if concurrency is important.
>
> From what I understand about the latter option, it would mean building your own event-bus
or listeners.
> As for the java.beans, a possible solution to avoid deprecation right now would be include
the java.beans property listeners code in [lang]. Maybe internal only.

AFAIK we cannot copy any JVM code into our codebase, even if marked internal.
It would have to be a clean-room implementation.

> Bruno
>
>       From: Gilles <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
>
>
>
>

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


Mime
View raw message