Skip to main content

[javaee-spec users] [jsr342-experts] Re: allowing stereotypes to be used more widely

  • From: Bill Shannon <bill.shannon@...>
  • To: jsr342-experts@...
  • Subject: [javaee-spec users] [jsr342-experts] Re: allowing stereotypes to be used more widely
  • Date: Thu, 20 Sep 2012 23:56:25 -0700
  • List-id: <jsr342-experts.javaee-spec.java.net>

As with my previous message, I'd like to hear from the rest of the
expert group on this topic.

Bill Shannon wrote on 08/30/2012 01:58 PM:
> Some time ago David Blevins started a discussion in the EJB expert
> group about "meta-annotations".  The thread starts here:
> http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2011-12/message/21
> 
> Several of us have been discussing this idea privately on and off
> for some time, and it's time to bring that discussion to this expert
> group.  The general idea is to allow developers to create their own
> annotations that are combinations of existing annotations.  You can
> think of this as a limited "macro" facility for annotations.
> 
> For example:
> 
> @Metatype
> @Stateless
> @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
> public @interface NonTransactional { }
> 
> @NonTransactional
> public class MyStatelessEJB { ... }
> 
> 
> This is essentially CDI stereotypes, which leads to a counter-proposal
> to simply allow CDI stereotypes to be used more widely.
> 
> The issues with using stereotypes more widely are:
> 
> - Stereotypes are implemented by CDI, but (typically) the Java EE
>   deployment processing has no knowledge of CDI when it's looking
>   for Java EE annotations.  Integrating with CDI so that stereotypes
>   could be considered during this deployment-time annotation processing
>   would require a new CDI SPI.
> 
> - CDI extensions can change the definition of a stereotype.  Because
>   most Java EE annotations are processed at deployment time, before
>   any application code (including CDI extensions) can run, any dynamic
>   changes to stereotypes can't effect the deployment process.
> 
> - The additional processing required at deployment time to handle
>   stereotypes could have a non-trivial impact on deployment performance.
> 
> To address these issues, we could introduce a new @Metatype annotation
> with most of the same functionality as stereotypes, but without the
> ability to change them dynamically.  Of course, introducing a new
> annotation has issues of its own:
> 
> - Developers will be confused as to when to use @Stereotype and when
>   to use @Metatype.  In most, but not all, cases they will behave
>   similarly.
> 
> - Introducing a new annotation, without a common place to handle
>   processing of that annotation, will likely lead to inconsistencies
>   in its implementation.
> 
> 
> Our preliminary analysis suggests that the performance impact of
> handling stereotypes when processing deployment time annotations
> will not be significant.  While there's a very small incremental
> cost to be *able* to handle stereotypes, most of the actual cost
> is only incurred if applications *use* stereotypes.  And in any
> event, the cost would be essentially the same as the @Metatype
> approach.
> 
> Based on our experience so far, very few developers make use of the
> dynamic capabilities of stereotypes.  That fact, along with the
> potential confusion of having two annotations that are almost but
> not exactly the same, makes it attractive to consider enhancing
> the definition of stereotypes to indicate that when they're used
> with Java EE annotations, the definition of the stereotype is static
> at deployment time.  Of course, this also requires a tighter
> integration of CDI with the rest of the Java EE platform, which
> seems to be the direction we're moving on several fronts.  (More
> on that later.)
> 
> Using stereotypes for this purpose would only work when CDI is
> enabled.  Separately, the CDI expert group is considering whether we
> should change the default and enable CDI by default.  Doing so would
> make this approach more attractive, although it may also introduce
> additional performance issues that would need to be addressed.
> 
> Allowing the use of stereotypes for this purpose requires changing
> many existing annotations to include ANNOTATION_TYPE as a @Target.
> 
> Many existing implementations would need to be changed to understand
> how to expand stereotypes.  Requiring every technology to do this
> itself will almost certainly lead to inconsistencies.  Since stereotypes
> are a CDI feature, CDI will provide a simple replacement for the
> java.lang.reflect methods such as getAnnotations that takes into
> account stereotypes.
> 
> Some technologies will not want to have a hard dependency on CDI so
> we'll need to provide a simple way for them to conditionally invoke
> these new methods only if CDI is present, falling back to java.lang.reflect
> if not.  This seems straightforward.  In this case, the functionality of
> @Stereotype would not be available to applications that chose to run
> without CDI.
> 
> What do you think of the above approach?  Is expanding the use of
> @Stereotype the best approach?  Or are the issues with that approach
> significant enough that we should consider introducing a new annotation
> for this purpose?
> 



[javaee-spec users] [jsr342-experts] Re: allowing stereotypes to be used more widely

David Blevins 09/01/2012

[javaee-spec users] [jsr342-experts] Re: allowing stereotypes to be used more widely

Werner Keil 09/01/2012

[javaee-spec users] [jsr342-experts] Re: allowing stereotypes to be used more widely

David Blevins 09/04/2012

[javaee-spec users] [jsr342-experts] Re: allowing stereotypes to be used more widely

Werner Keil 09/04/2012

<Possible follow-up(s)>

[javaee-spec users] [jsr342-experts] Re: allowing stereotypes to be used more widely

Bill Shannon 09/21/2012
 
 
Close
loading
Please Confirm
Close