You can use LinkedTransferQueue for inter thread notifications (or
ArrayBlockingQueue). Read side can either block and wait for items to enter
the queue, or you can use atomics to implement low latency forms of those
queues (but high CPU usage).
On Fri, Jul 20, 2018 at 05:06, Gilles wrote:
> Hi.
>
> On Fri, 20 Jul 2018 09:47:21 +0100, sebb wrote:
> > On 20 July 2018 at 00:09, Bruno P. Kinoshita
> > 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.
>
> I've read that Observer/Observable will not be removed from the
> JDK (but won't be maintained). So, if the shortcomings are OK
> for the purpose at hand, the issue is only the deprecation warning.
>
> Does someone readily knows how to go about implementing an equivalent
> functionality with "java.util.concurrent" classes?
>
> Regards,
> Gilles
>
> >> 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
> >> 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 + (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
> >>> 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
> >>>
