Hi Joel,

If you make Executable.declaredAnnotations field volatile, synchronization is only necessary on the 'root' instance:


private transient volatile Map<Class<? extends Annotation>, Annotation> declaredAnnotations;

private Map<Class<? extends Annotation>, Annotation> declaredAnnotations() { Map<Class<? extends Annotation>, Annotation> anns = declaredAnnotations;
        if (anns == null) {
            Executable root = getRoot();
            if (root != null) {
                declaredAnnotations = anns = root.declaredAnnotations();
            } else {
                synchronized (this) {
declaredAnnotations = anns = AnnotationParser.parseAnnotations(
                        getAnnotationBytes(),
sun.misc.SharedSecrets.getJavaLangAccess().
getConstantPool(getDeclaringClass()),
                        getDeclaringClass());
                }
            }
        }
        return anns;
    }


Regards, Peter

On 08/14/2014 06:54 PM, Peter Levart wrote:
On 08/14/2014 08:47 AM, Joel Borggren-Franck wrote:
On 2014-08-13, Joe Darcy wrote:
Hi Joel,

Does your changeset alter the support (or non-support) of redefining
an annotation?

Hi Joe,

It does not interact with the current non-support and I am convinced it
wont hinder us in improving the situation.

cheers
/Joel
Hi Joel,

Good to see this patch. It improves the efficiency of annotations caching on methods/constructors. What about fields? They too are AccessibleObject(s), contain annotations and are copied from root instances when handed over to the user...

The difference of behaviour in the presence of class redefinition could be observed though, but I think this is not a problem. For example:

Class c = ...;

Method m1 = c.getDeclaredMethod("m");
Method m2 = c.getDeclaredMethod("m");

assert m1 != m2; // but they share the same root;

Annotation[] anns1 = m1.getDeclaredAnnotations();

// now class 'c' is redefined and annotations changes on method m()...

Annotation[] anns2 = m2.getDeclaredAnnotations();

// previously anns1 / anns2 would countain annotations pre / post class redefinition, but with this patch, they would both contain the pre class redefinition annotations.


But as I see it this is not a big problem to hold the patch back.


Regards, Peter


Reply via email to