[cdi-dev] Mutable annotation literals

Pete Muir pmuir at redhat.com
Thu Aug 16 09:01:48 EDT 2012


On 16 Aug 2012, at 13:58, Mark Struberg wrote:

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

Agreed.

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

Yes.

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

Except that the hash code rules for annotations aren't that easy to follow.

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




More information about the cdi-dev mailing list