Re: [cdi-dev] Mutable annotation literals

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(a)redhat.com&gt; > To: Mark Struberg <struberg(a)yahoo.de&gt; > Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; > 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(a)redhat.com&gt; >>> To: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >>> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >