You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Roger Whitcomb <rw...@apache.org> on 2017/05/13 06:04:15 UTC

Any idea why we have WTKListenerList

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
}


RE: Any idea why we have WTKListenerList

Posted by Roger Whitcomb <Ro...@actian.com>.
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:RogerandBeth@rbwhitcomb.com] 
Sent: Tuesday, May 16, 2017 5:25 PM
To: Sandro Martini <sa...@gmail.com>
Cc: rwhitcomb@apache.org; Developers - Apache Pivot <de...@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 <sa...@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" <rw...@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" <rw...@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
>>>> }
>>>> 
>> 


Re: Any idea why we have WTKListenerList

Posted by Roger and Beth Whitcomb <Ro...@rbwhitcomb.com>.
Sure. I'm fine with that. Will do that shortly. 

Thanks,
~Roger


> On May 16, 2017, at 4:13 PM, Sandro Martini <sa...@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" <rw...@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" <rw...@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
>>>> }
>>>> 
>> 

Re: Any idea why we have WTKListenerList

Posted by Sandro Martini <sa...@gmail.com>.
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" <rw...@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" <rw...@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
>> }
>>
>>
>

Re: Any idea why we have WTKListenerList

Posted by Roger Whitcomb <rw...@apache.org>.
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" <rwhitcomb@apache.org 
> <ma...@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
>     }
>


Re: Any idea why we have WTKListenerList

Posted by Sandro Martini <sa...@gmail.com>.
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" <rw...@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
> }
>
>