[cdi-dev] Mutable annotation literals

[Mark Struberg]

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.


LieGrue,
strub



----- 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
>>> 
>