There are a number of issues with weak references that, IMO, make them unsuitable for event registration. As Noel noted, they can easily disappear, causing developer confusion. This is true even for non-anonymous listener classes:
something.addListener(new ConcreteListener()); If the registering class itself implements the listener interface, this may not be as much of a problem (assuming that another reference to this is maintained elsewhere): something.addListener(this); However, the down side to this approach is that the listener methods are now exposed in the class's public API. This breaks encapsulation and pollutes the API. Inner classes allow the listener to call private handlers in the outer class, which preserves encapsulation. However, they are prone to the issue mentioned in Noel's original email. I don't think it is accurate to say that "strong references lead to memory bloat". Developers simply need to be cognizant that, if a listener is added, it must also be removed. In most cases, this isn't a problem, because the lifetime of the listener parallels the lifetime of the event-firing object. Because the other cases are more rare, manually removing references should be easily manageable. G On Jun 20, 2010, at 7:12 PM, aappddeevv wrote: > Sandro, > > Thanks. BTW, I think that anytime you touch annotations, it always seems to > involve larger, more complex code and I understand the concern. Just on > those grounds is sufficient reason to not include it. > > With regard to weak listeners, I believe that we are talking about two > different areas of registration of message listeners. Under the proposal, > its not an anonymous class that is being weakly referenced but just the > target instance that has the annotated method. The current code has weak > references or strong, they are both in there. But I really do think we are > talking about two different objects in this conversation. > > For message processing, sometimes the opposite is true--strong references > lead to memory bloat due to not cleaning up resources correctly especially > when you register into a singleton static object. I'll spin another version > and add some comments. Because of the briefness of the subscribe/unsubscribe > interface in the application context, a small amount of machinery has to be > added that helps with listener subscription and unsubscription. > > > > -----Original Message----- > From: Sandro Martini (JIRA) [mailto:j...@apache.org] > Sent: Sunday, June 20, 2010 4:48 PM > To: dev@pivot.apache.org > Subject: [jira] Commented: (PIVOT-535) Add a @MessageListener annotation and > an annotation processor for application context message listener > > > [ > https://issues.apache.org/jira/browse/PIVOT-535?page=com.atlassian.jira.plug > in.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880671#action_1 > 2880671 ] > > Sandro Martini commented on PIVOT-535: > -------------------------------------- > > Hi to all, > I like the proposal, and generally speaking anything that could help to > simplify/extend user code in a simpler way. > But I agree that I'd like to exclude code too complex to mantain or too > "foreign" respect to Pivot philosophy. > > So, what do you think on an initial (experimental) version without weak > listeners ? > > > And finally, Appddevvv, thank you for sharing/discuss with us many things > and improvements on Pivot. > > Bye, > Sandro > > >> Add a @MessageListener annotation and an annotation processor for > application context message listener >> > ---------------------------------------------------------------------------- > -------------------------- >> >> Key: PIVOT-535 >> URL: https://issues.apache.org/jira/browse/PIVOT-535 >> Project: Pivot >> Issue Type: Improvement >> Reporter: Appddevvv >> >> Add a message listener annotation and a static method for annotation > processing to automatically enroll instance/methods in application message > handling. >> I have the classes that I can submit as a starting point. They allow weak > and strong references as well as optional request-reply semantics. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. >
