If I mark the class as deprecated, then we get 100s of warnings in the build. I'd rather not do that on the branch we're about to release (2.0.5).... So, I will mark it "@Deprecated" in "trunk", while at the same time changing the rest of the code not to use it....
-----Original Message----- From: Roger and Beth Whitcomb [mailto:rogerandb...@rbwhitcomb.com] Sent: Tuesday, May 16, 2017 5:25 PM To: Sandro Martini <sandro.mart...@gmail.com> Cc: rwhitc...@apache.org; Developers - Apache Pivot <dev@pivot.apache.org> Subject: Re: Any idea why we have WTKListenerList Sure. I'm fine with that. Will do that shortly. Thanks, ~Roger > On May 16, 2017, at 4:13 PM, Sandro Martini <sandro.mart...@gmail.com> wrote: > > Ok, I'm fine with the remove in trunk. > But before that we could put it deprecated in 2.0.x ... do you agree ? > > Bye > > Il 16/Mag/2017 00:09, "Roger Whitcomb" <rwhitc...@apache.org> ha scritto: >> Ciao Sandro, >> >> I'm skeptical that it needs to have any multi-thread checks because >> pretty much everything in WTK has to happen on the AWT Event Dispatch >> Thread, or things go awry. >> >> In fact, the first two commits to "WTKListenerList" were these: >> >> r1153866 | noelgrandin | 2011-08-04 05:37:00 -0700 (Thu, 04 Aug 2011) >> | 2 lines >> >> PIVOT-780 Can't use BXMLSerializer from non-AWT threads makes >> background resource loading impossible make the EDT checker tolerant >> of constructing WTK hierarchies from outside the event thread >> --------------------------------------------------------------------- >> --- >> r1101054 | noelgrandin | 2011-05-09 08:07:59 -0700 (Mon, 09 May 2011) >> | 1 line >> >> add sanity checks to prevent updates to WTK state from happening >> except from the event dispatch thread >> >> >> Checking the diffs for revision 1153866 -- the WTKListenerList class was >> gutted to take OUT all the checks for being on the EDT, so that component >> hierarchies could be built up on background threads. >> >> So, I'm going to pretty confidently assert that we no longer need this class >> (at least in "trunk") and proceed to remove it .... (in a week or two to >> allow for more comment). >> >> Thanks, >> ~Roger >> >>> On 5/15/17 1:19 PM, Sandro Martini wrote: >>> Hi Roger, >>> I don't remember the originale reason for that class (maybe Greg could) ... >>> >>> You (or someone other) uses it in a multi thread environment ? >>> If Yes, maybe could be a feature nice to have and we could get some time to >>> finish its implementation (and related test case) ... >>> >>> What do you think ? >>> >>> Bye >>> >>> >>> Il 13/Mag/2017 08:04, "Roger Whitcomb" <rwhitc...@apache.org> ha scritto: >>>> Hi all, >>>> >>>> I'm looking at WTKListenerList.java and it says it was implemented to >>>> add thread-safety to the ListenerList abstract class. But, AFAICT it does >>>> no such thing; it's simply an alias for ListenerList<T>. Is this >>>> something that just never got implemented (the "thread safety" aspect)? >>>> Or is thread safety not needed in these cases? Or ....? >>>> >>>> Trying to simplify code, for 2.1, so I'm thinking about getting rid of >>>> it, unless I need to worry about thread safety not being in here.... >>>> >>>> Thanks, >>>> ~Roger >>>> >>>> /** >>>> * This is a customized subclass of ListenerList that adds >>>> thread-safety checks >>>> * for the WTK components. >>>> */ >>>> public class WTKListenerList<T> extends ListenerList<T> { >>>> // empty block >>>> } >>>> >>
