It was quite a while ago that I tried, probably around JDK 1.2.2. I've only ever run across a couple of memory leaks related to strong listeners, and they were dead-easy to find and kill - just follow the this$0 reference.
Weak listeners on the other hand, manifested as UI controls that would work for a while, and then stop listening. Which was a major pain to find and fix. You're right - this is much less of a problem with modern VM's because the GC strategy so aggressively collects short-lived objects. -- Noel Grandin Michael Bushe wrote: > How long ago was that experience with weak listeners? VMs since 1.5 > (maybe 1.4) would collect a weak listener before the next statement > after subscribe() executes. Try to get a test to pass with a weak > listener, it's been a long time since I've seen it. > > Even if that were not true, failing after a few minutes is a lot > better than a memory leak as slow to close as the BP's Gulf Gusher. > > Michael Bushe > Principal > Bushe Enterprises, Inc. > [email protected] <mailto:[email protected]> > www.bushe.com <http://www.bushe.com> > www.mindfulsoftware.com <http://www.mindfulsoftware.com> > www.eventbus.org <http://www.eventbus.org> > > > On Tue, Jun 22, 2010 at 2:59 AM, Noel Grandin <[email protected] > <mailto:[email protected]>> wrote: > > Hi > > Unfortunately, weak listeners don't "fail fast". In my experience, > with > large applications, weak listeners generally take a couple of > minutes to > fail, which makes them quite painful to track down. > > I think the reason you don't see this issue is because your primary > pattern doesn't use anonymous inner classes. > > But yes, I can see how weak listeners will make life-cycle management > easier when your listeners are methods on a normal class. > > -- Noel Grandin > > Michael Bushe wrote: > > In my experience in supporting users of the EventBus, in both > the open > > source world and in professional teams, weak references are not > something to > > be feared. This is because: > > 1) Weak references fail fast. > > 2) Weak reference semantics can be documented. Make the API's > clear, make > > the doc clear, make the examples clear. Document the > anti-pattern, put it > > in the FAQ. > > 3) Assume your users are smarter than you might think. > WeakReferences are > > pretty easy to understand. Even if a rookie doesn't understand > them, you > > can make it a teachable moment. > > 4) WeakReferences are clean and simple. Managaging listener > lifecycle is > > like managing memory in C- it a buggy job that sucks > productivity and bloats > > code. > > 5) In the 6 years of the EventBus' life, only one user posted a > "this > > doesn't work" question because they didn't RTFM. > > > > Greg, you didn't detail many of the "number of issues" with > WeakReferences, > > so I'm not sure what the perception is, but in my experience > WeakReferences > > are better since the lifecycle of the listener is generally (90%+) > > equivalent to the lifecycle of the component that defines the > listener. > > > > One issue mentioned is the use of an anonymous inner class (a > questionable > > pattern anyway), but when annotations are available users > generally use that > > more terse route rather than using an anonymous class. When > developers use > > the anonymous class anti-pattern, it fails quickly and they > change it - > > often forcing them to think about garbage collection in their > apps, which is > > a great thing. The corollary of using .subscribe(new > XXXSubscriber()) is > > even worse when using strong references - without a reference it's > > impossible to clean up. > > > > I think the encapsulation argument is extremely weak. Firstly, > most UI > > developers don't care too much about building extensible > classes, but even > > when they do, I prefer the opposite effect: Each method that is > annotated as > > a subscriber becomes part of the contract of the component. > This is a form > > of programming by contract that is very powerful. It says, > "whenever this > > event is fired, I'm going to call this method." Derived classes can > > manipulate the behavior as needed. Hiding it is equivalent to > the static > > final listeners that are all over the Swing framework - it stops > extension > > and customization in it's tracks. I went into this pub/sub > > programming-by-contract method quite a bit in the > > > > article<http://eventbus.org/confluence/pages/viewpage.action?pageId=819222#EventBus%26ApachePivotorRefactoringUIstoUsePub-Sub-Contracts>I > > wrote on the EventBus+Pivot. Lastly, if you don't like that > idea, you > > can > > easily create private fields that are listeners. > > > > The best argument for weak references is that strong references > generally > > suck. Strong references have the opposite effects listed above: > > 1) Strong references cause memory "leaks" that don't fail fast. > They fail > > very slowly and insiduously. They are often not caught until > production. > > 2) Strong reference issues are hard to document. > > 3) Even smart, experienced developers wind up wasting hours or > days tracking > > down memory leaks before they find the culprit. > > 4) Lifecycle management of listeners is not always easy. It is > error prone > > and bloats code. Even in the easy cases, it's easily forgotten and > > difficult to test for. > > > > Note: The Spring ActionScript EventBus shifted (is shifting?) from > > defaulting to strong to defaulting to weak. > > > > I look forward to seeing how the MessageBus API develops. > > > > Michael Bushe > > Principal > > Bushe Enterprises, Inc. > > [email protected] <mailto:[email protected]> > > www.bushe.com <http://www.bushe.com> > > www.mindfulsoftware.com <http://www.mindfulsoftware.com> > > www.eventbus.org <http://www.eventbus.org> > > > > On Mon, Jun 21, 2010 at 4:33 PM, aappddeevv > <[email protected] <mailto:[email protected]>> wrote: > > > > > >> I think that's fair to do. > >> > >> -----Original Message----- > >> From: Greg Brown [mailto:[email protected] <mailto:[email protected]>] > >> Sent: Monday, June 21, 2010 2:11 PM > >> To: [email protected] <mailto:[email protected]> > >> Subject: Re: [jira] Commented: (PIVOT-535) Add a @MessageListener > >> annotation > >> and an annotation processor for application context message > listener > >> > >> It doesn't necessarily need to be used by other parts of the > framework to > >> go > >> in pivot-core. It just needs to be generally useful and not > have any > >> dependencies on the other libraries. > >> > >> I'm not sure what else, if anything, I would want it to do - it > is really > >> only meant to provide simple intra-application messaging > services without a > >> lot of overhead or the need for an external library. > >> > >> One advantage to moving it to org.apache.pivot.util is that > listener > >> implementations would not require so much typing > (MessageBusListener is > >> shorter than ApplicationContextMessageListener). Also, since (like > >> WTKXSerializer) it isn't strictly dependent on WTK, it probably > does not > >> belong there. > >> > >> G > >> > >> On Jun 21, 2010, at 11:53 AM, aappddeevv wrote: > >> > >> > >>> Yes. But I would leave it there for now. For simple messaging > it is > >>> sufficient. More thought is needed. My current thinking is > that unless it > >>> used by pivot internally, and hence drives need & evolution, > it could be > >>> better to use something else. > >>> > >>> > >>> -----Original Message----- > >>> From: Greg Brown [mailto:[email protected] <mailto:[email protected]>] > >>> Sent: Monday, June 21, 2010 9:52 AM > >>> To: [email protected] <mailto:[email protected]> > >>> Subject: Re: [jira] Commented: (PIVOT-535) Add a @MessageListener > >>> > >> annotation > >> > >>> and an annotation processor for application context message > listener > >>> > >>> > >>>> One thing I am finding is for annotations and > auto-registering, that the > >>>> machinery dominates the actual messaging code in > ApplicationContext. > >>>> > >>> ApplicationContext is large, but the message handling code > itself is > >>> > >> pretty > >> > >>> small - it is just a few methods: > >>> > >>> subscribe() > >>> unsubscribe() > >>> sendMessage() > >>> queueMessage() > >>> > >>> I have actually been wondering if it might make sense to move > it to a > >>> > >> core > >> > >>> class, such as org.apache.pivot.util.MessageBus so that non-UI > >>> > >> applications > >> > >>> can also use it. The only thing specific to WTK is > queueMessage(), but > >>> > >> that > >> > >>> could either remain in ApplicationContext and be implemented > in terms of > >>> MessageBus, or it could potentially be eliminated - the code > in that > >>> > >> method > >> > >>> could easily be implemented at the application level. > >>> > >>> > >> > >> > > > >
