Skip to main content

[javaee-spec users] [jsr342-experts] Re: annotations vs. interfaces

  • From: Pete Muir <pmuir@...>
  • To: jsr342-experts@...
  • Subject: [javaee-spec users] [jsr342-experts] Re: annotations vs. interfaces
  • Date: Tue, 9 Oct 2012 19:56:08 -0700
  • List-id: <jsr342-experts.javaee-spec.java.net>

Agreed. I was trying to highlight this point in my other mail, where I said a 
reason to use annotations was if not all methods were required, exactly once.

On 5 Oct 2012, at 01:27, Florent BENOIT wrote:

> What I like with annotation in the first example is when you don't want to 
> override every methods
> If you only want to apply one a single listener method it make sense
> 
> Like for Stateful Session Bean
> In the past you had to implements javax.ejb.SessionSyncrhonization and for 
> example have empty methods if you only want to apply for a single listener 
> callback
> 
> With listener annotation you can only be notified for a set of event like 
> @AfterBegin or @BeforeCompletion
> 
> 
> Regards,
> 
> Florent
> 
> On Fri, Oct 5, 2012 at 1:52 AM, Jeff Genender <jgenender@...> wrote:
> I agree with your view on the batch API and your proposal to the "rules".  
> They seem pretty straight forward to me.
> 
> Jeff
> 
> On Oct 4, 2012, at 3:36 PM, Bill Shannon <bill.shannon@...> wrote:
> 
> > Earlier this year I wrote up a bunch of our "rules" for how annotations
> > should work: http://java.net/projects/javaee-spec/pages/AnnotationRules
> >
> > While reviewing the Batch spec:
> > http://download.oracle.com/otndocs/jcp/batch-1_0-edr-spec/index.html
> > I noticed that they were using annotations in places that I expected
> > to see interfaces.
> >
> > For example, they allow a class to be a "listener" for events, and they
> > declare that the class is a listener by annotating the class.  To indicate
> > which method of the class should be called when the event occurs, they
> > annotate the method.  The different events are a finite and fixed set,
> > and each type of listener handles only a few events associated with that
> > type.  You might have:
> >
> > @JobListener
> > public class MyJobListener {
> >    @JobStarted
> >    public void jobStarted() { ... }
> >    @JobFinished
> >    public void jobFinished() { ... }
> > }
> >
> > To me, this just felt like an abuse of annotations in a place where a
> > listener interface is a widely used and well understood approach.
> > Why would you not simply do:
> >
> > public interface JobListener {
> >    public void jobStarted();
> >    public void jobFinished();
> > }
> >
> > public class MyJobListener implements JobListener {
> >    public void jobStarted() { ... }
> >    public void jobFinished() { ... }
> > }
> >
> > Of course, you'll want an annotation on MyJobListener to configure
> > the listener and associate it with a specific job.  (You don't want
> > a class to be used just because it's been declared.)
> >
> > It seemed like it would be worth writing down some general principles
> > as an update to my annotation rules page above.  Here's what I have so
> > far, but I'd love your feedback.  Of course, it's likely that we haven't
> > followed a consistent set of rules for things we've already done, so there
> > will always be exceptions.  Let me know if you agree with the following,
> > and especially let me know of any additions.
> >
> >
> > - When defining an API that an application is going to implement and
> >  the container is going to call, use an interface.
> >
> > - To configure the container to use a particular implementation of such
> >  an interface in a particular situation, use an annotation.
> >
> > - If an application class is providing an API that's exposed to other
> >  applications, and that class also needs to provide methods that the
> >  container will call for lifecycle functions, use an annotation to
> >  mark those methods so that the application has flexibility in the
> >  choice of names for those methods.
> >
> > - If an application is going to expose an interface that another
> >  application (or user) is going to use *without* Java, use annotations
> >  to mark the methods that correspond to this interface.  This avoids
> >  the need to define a Java interface that's never going to be used by
> >  anyone other than the one class implementing the interface.
> 
> 



[javaee-spec users] [jsr342-experts] annotations vs. interfaces

Bill Shannon 10/04/2012

[javaee-spec users] [jsr342-experts] Re: annotations vs. interfaces

Jeff Genender 10/04/2012

[javaee-spec users] [jsr342-experts] Re: annotations vs. interfaces

Florent BENOIT 10/08/2012

[javaee-spec users] [jsr342-experts] Re: annotations vs. interfaces

Pete Muir 10/10/2012

[javaee-spec users] [jsr342-experts] Re: annotations vs. interfaces

Pete Muir 10/08/2012

[javaee-spec users] [jsr342-experts] Re: annotations vs. interfaces

Bill Shannon 10/09/2012

[javaee-spec users] [jsr342-experts] Re: annotations vs. interfaces

Pete Muir 10/10/2012
 
 
Close
loading
Please Confirm
Close