Hi Bill,
hi all,
I'm generally against introducing duplicate functionality with
different names. So this would mean to support
the use of one annotation.
I can't comprehensively comment on the CDI dependency issues. What I
see is, that there is a point for
being able to run _without_ it in standalone environments. To my
understanding this also was the reason
why JSF decided to keep the javax.faces.bean.ManagedBean and don't
depend on @javax.inject.Named.
On the other side, there is hardly any Java EE 6 project _not_ using
CDI at all. So, if we have a working
fallback scenario I would strongly support introducing the CDI
dependency. This also would allow to
remove the inconsistent solutions (JSF) over time and move forward
faster with the overall programming model.
The other important part I see is the performance. (Re-) Deployment
performance is crucial and it needs to be
near to the possible optimum. As long as we don't introduce a
significant impact here, it would be ok. Otherwise
this is a show-stopper for me.
Bottom line: please expand the @Stereotype use as described.
- Markus
On 30 August 2012 22:58, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> 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?