On 20 July 2018 at 00:09, Bruno P. Kinoshita <brunodepau...@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 <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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
