Skip to main content

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

  • From: Pete Muir <pmuir@...>
  • To: jsr342-experts@...
  • Subject: [javaee-spec users] [jsr342-experts] Re: allowing stereotypes to be used more widely
  • Date: Tue, 20 Nov 2012 13:47:27 +0000
  • List-id: <jsr342-experts.javaee-spec.java.net>

Hi Markus

On 20 Nov 2012, at 07:36, Markus Eisele wrote:

> Hi Pete,
> hi Bill,
> 
> I would like to support Bills view here. Extension development doesn't
> has a strong day-to-day use-case and I am in strong favor of making
> the platform easier to use for at least 90% of the users.

So am I. However when we weigh the two options:

(a) subtly alter the way stereotypes work, with the issue I described
(b) introduce a new concept like stereotypes, that are purely defined at 
compile time

then I believe the cost of (b) does not outweigh the cost of (a).

I much prefer stuff that is simple to explain, and I really dislike changing 
how something works once people start using it.

For example:

"We've introduced metatypes in Java EE 7, which allow you to meta-annotate 
your classes, and have those annotations transitively applied. CDI takes 
metatypes one step further, and allows you to make it a stereotype, in which 
case some special CDI rules apply".

That to me is a simple and clear. Vs

"We've extended stereotypes to the Java EE platform. They work mostly like 
you are used to in CDI in Java EE 6, except for these points:

* In general, any annotation on a metatype is applied to your class
* CDI specific rules are still applied, so don't expect @Named and scopes to 
work like this, quite (@Named can only be used to provide a default name on a 
sterotype, you can only specify one scope, and if you put any scope at the 
class level it overrides the one on the stereotype)
* If you use a portable extension to apply a stereotype, you can only expect 
the CDI specific rules to be applied to a bean, so for example using an EJB 
annotation here won't have any effect."

To me, this is pretty much the opposite of making the platform easier. It's 
making it more confusing.

> Don't you
> believe the mentioned arguments could be easily handled by the
> extension developers if there is a solid documentation ?

Well, I definitely don't believe in "designing for FAQs" (IOW if you know up 
front that a piece of design you do is going to need a FAQ, then really 
strongly consider whether there is a better alternative), so the fact that 
you deploy this argument makes me more convinced it's the wrong approach.

> 
> - M
> 
> On 19 November 2012 23:34, Bill Shannon <bill.shannon@...> wrote:
>> We knew about this issue from the beginning.
>
>> The proposal to reuse @Stereotype was based on the assertion that 99% of
>> CDI users never write a portable extension, and of those who do, very
>> few do anything like this.
>
>> Yes, those few would have to understand the limitations, but 99% of the
>> users would not need to know or care.
>
>> The alternative is that 100% of users need to know whether to choose
>> @Stereotype or @Metatype (or whatever we end up calling it), even though
>> both will work in many cases.
>
>> I'd rather confuse 1% of users in rare cases than 100% of users in common
>> cases.
>
>> Remember that in no case will what you've shown below be made to work,
>> so someone needs to know about that no matter what we do.
>
>> But this is the argument I made before, which apparently isn't 
>> compelling...
>
>> Pete Muir wrote on 11/19/12 06:34:
>>> I was on the fence for a long time, however discussing with the CDI EG 
>>> and colleagues made it clear there was little support once we went 
>>> through the possible confusion that can arise.  The CDI EG also agrees 
>>> with me here :-)
>>> 
>>> Here is the point which we think kills the idea. If you define this 
>>> stereotype in CDI, with the support proposed for all Java EE specs:
>>> 
>>> @Stereotype
>>> @RequestScoped
>>> @Stateless
>>> public @interface MyStereotype {}
>>> 
>>> And define this bean:
>>> 
>>> @MyStereotype
>>> public class MyBean {}
>>> 
>>> you end up with a request scoped SLSB.
>>> 
>>> If you also define this bean:
>>> 
>>> public class MyOtherBean {}
>>> 
>>> and write a portable extension:
>>> 
>>>    public <X> void addMyStereotype(@Observes ProcessAnnotatedType<X> pat) 
>>> {
>>>        if 
>>> (pat.getAnnotatedType().getJavaClass().getName().equals("MyOtherBean")) {
>>>            Annotation myStereotype = new 
>>> AnnotationLiteral<MyStereotype>() {};
>>>            AnnotatedType<X> at = new 
>>> AnnotatedTypeBuilder().read(pat.getAnnotatedType()).addAnnotation(myStereotype).build();
>>>            pat.setAnnotatedType(at);
>>>        }
>>>    }
>>> 
>>> which looks for MyOtherBean, and then adds the @MyStereotype annotation 
>>> (using an AnnotatedTypeBuilder provided e.g. by DeltaSpike).
>>> 
>>> Naively, a user would expect @Stateless to be applied to MyOtherBean, 
>>> however it will not. We feel this is a much more confusing situation than 
>>> simply saying the you cannot put any other annotations on a stereotype 
>>> than certain CDI annotations.
>>> 
>>> Hope that helps explain the issue
>>> 
>>> Pete
>>> 
>>> On 16 Nov 2012, at 23:22, Bill Shannon wrote:
>>> 
>>>> Very recently.
>>>> 
>>>> He may have held this position for a long time, but it only became
>>>> clear to me very recently.
>>>> 
>>>> Werner Keil wrote on 11/16/12 13:47:
>>>>> Sorry,   this thread mentioned is about a year old.
>>>>> When did Pete state that, last year or just recently?
>>>>> 
>>>>> Thanks,
>>>>> Werner
>>>>> 
>>>>> I hope you've all had a chance to contribute to the Java EE 7 survey
>>>>> Linda announced recently.  If you've looked at the results, you'll
>>>>> see that 65% of the people support expanding our use of @Stereotype,
>>>>> with only 11% thinking it's a bad idea.
>>>>> 
>>>>> Unfortunately, it turns out that the CDI spec lead doesn't agree
>>>>> that we should reuse @Stereotype in this way, and would prefer that
>>>>> we define a new annotation for this purpose.  Without support from
>>>>> CDI, we can't reuse @Stereotype, so we'll need to consider the
>>>>> alternative.  Sadly, at this late date, we don't have time and
>>>>> resources to define, implement, and test an alternative solution.
>>>>> I'm afraid this is something we'll need to reconsider for Java EE 8.
>>>>> 
>>>>> I still think the general idea is a great idea and I look forward to
>>>>> fleshing it out for EE 8!
>>>>> 
>>>>> Bill Shannon wrote on 08/30/12 13:58:
>>>>>> 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

Bill Shannon 11/16/2012

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

Werner Keil 11/16/2012

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

Bill Shannon 11/16/2012

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

Pete Muir 11/19/2012

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

Bill Shannon 11/19/2012

Message not available

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

Markus Eisele 11/20/2012

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

Pete Muir 11/20/2012

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

Marina Vatkina 11/19/2012

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

Bill Shannon 11/20/2012

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

Marina Vatkina 11/20/2012

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

Bill Shannon 11/20/2012
 
 
Close
loading
Please Confirm
Close