[cdi-dev] Mutable annotation literals

Mark Struberg struberg at yahoo.de
Thu Aug 16 08:58:53 EDT 2012

The problem is an AnnotationLiteral could theoretically be mutable as well. Thus the AnnotationLiteral class must not make such assumptions imo. 

I the case of an empty value-methods list we could btw also improve the equals method.

In the case where you have value-methods, you already need to implement the interface manually. It would be no problem to just add the 2 lines for caching the hashCode in case the values do not change.


----- Original Message -----
> From: Pete Muir <pmuir at redhat.com>
> To: Mark Struberg <struberg at yahoo.de>
> Cc: cdi-dev <cdi-dev at lists.jboss.org>
> Sent: Thursday, August 16, 2012 2:20 PM
> Subject: Re: [cdi-dev] Mutable annotation literals
> I guess what Marko/I am proposing is that we provide a utility for the common 
> case of an immutable annotation literal with member values...
> On 16 Aug 2012, at 13:18, Mark Struberg wrote:
>>  Imo we don't need to cache the hashCode in the AnnotationLiteral 
> itself. We just need to cache if there are value methods or not. If not, then we 
> can immediately return 0. If there are value methods present, then you need to 
> extend the AnnotationLiteral class anyway and can add an own hashCode which 
> delegates to super.hashCode() and caches the result if the values will not be 
> changed.
>>  LieGrue,
>>  strub
>>  ----- Original Message -----
>>>  From: Pete Muir <pmuir at redhat.com>
>>>  To: cdi-dev <cdi-dev at lists.jboss.org>
>>>  Cc: 
>>>  Sent: Thursday, August 16, 2012 1:43 PM
>>>  Subject: [cdi-dev] Mutable annotation literals
>>>  All
>>>  Marko has added caching for the hashcode value on AnnotationLiteral, 
> which is 
>>>  based on the premise that an AnnotationLiteral is not mutable.
> https://github.com/luksa/cdi/commit/f3c200fcdf8ca8681c194c921567aedcce375102
>>>  This is a reasonable thing to require (as real annotations are normally 
>>>  immutable!) and a very good optimisation, however it is not backwards 
>>>  compatible, as we have not previously required AnnotationLiteral to be 
>>>  immutable.
>>>  An alternative option is to introduce the ImmutableAnnotationLiteral 
> subclass, 
>>>  which would require any concrete instances to be immutable and could 
> use this 
>>>  optimisation. We could "deprecate" AnnotationLiteral (as 
> described in 
>>>  java.net/projects/javaee-spec/pages/CompatibilityRequirements).
>>>  Note that regardless, we can apply the minor optimisation suggested by 
> Mark, 
>>>  that we return 0 if the annotation has no members.
>>>  Pete
>>>  _______________________________________________
>>>  cdi-dev mailing list
>>>  cdi-dev at lists.jboss.org
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev

More information about the cdi-dev mailing list