Re: [cdi-dev] Mutable annotation literals
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>
To: cdi-dev <cdi-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev