Any idea why we have WTKListenerList

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Any idea why we have WTKListenerList

Roger Whitcomb
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
}

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Any idea why we have WTKListenerList

Sandro Martini
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" <[hidden email]> 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
> }
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Any idea why we have WTKListenerList

Roger Whitcomb
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" <[hidden email]
> <mailto:[hidden email]>> 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
>     }
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Any idea why we have WTKListenerList

Sandro Martini
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" <[hidden email]> 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" <[hidden email]> 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
>> }
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Any idea why we have WTKListenerList

Roger and Beth Whitcomb
Sure. I'm fine with that. Will do that shortly.

Thanks,
~Roger


> On May 16, 2017, at 4:13 PM, Sandro Martini <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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
>>>> }
>>>>
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Any idea why we have WTKListenerList

Roger Whitcomb-3
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:[hidden email]]
Sent: Tuesday, May 16, 2017 5:25 PM
To: Sandro Martini <[hidden email]>
Cc: [hidden email]; Developers - Apache Pivot <[hidden email]>
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 <[hidden email]> 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" <[hidden email]> 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" <[hidden email]> 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
>>>> }
>>>>
>>

Loading...