When retrieving metadata at runtime, the Class.getAnnotation() method appears straightforward, but its execution path relies heavily on JVM-level caching and dynamic proxy generation. Every annotated class maintains an internal AnnotationData instance that stores resolved metadata. This cache utilizes a Map<Class<? extends Annotation>, Annotation> where keys represent annotation types and values hold their corresponding runtime representations.

The retrieval process begins by inspecting this cache. If populated, the cached instance is returned immediately. During class initialization, the JVM reads constant pool attributes, extracts definition structures, and passes them to a parser. The parser constructs a mapping of annotation members to their resolved values. This mapping is subsequently used to instantiate a JDK dynamic proxy rather than a concrete implementation of the annotation interface.

Consider the following custom metadata definitions and their runtime resolution:

import java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface AppProfile {
    String environment() default "production";
}

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@AppProfile(environment = "staging")
public @interface ExtendedService {
}

public class MetadataResolver {
    public static void main(String[] args) {
        Class<?> targetClass = ExtendedService.class;
        AppProfile profile = targetClass.getAnnotation(AppProfile.class);
        
        if (profile != null) {
            System.out.println("Resolved Environment: " + profile.environment());
        }
    }
}

Executing this demonstrates immediate value access. However, deeper inspection reveals why checking for meta-annotations on the retrieved object behaves unexpectedly. The returned AppProfile instance is not a traditional object; its a JRE-generated proxy implementing the java.lang.annotation.Annotation contract.

Inside java.lang.reflect.Proxy, the annotation proxy delegates all method invocations to a specialized handler located in sun.reflect.annotation.AnnotationInvocationHandler. This handler stores the parsed member-value pairs in a private Map<String, Object>. When a getter method like environment() is invoked, the handler intercepts the call, extracts the method name, queries the backing map, and returns the stored result. If a requested member is missing, it throws an IncompleteAnnotationException.

This proxy architecture explains the behavior observed during composite or meta-annotation scenarios. Meta-annotations reside on the annotation type itself. When inspecting a proxy instance obtained via getAnnotation(), calling .getClass() yields the dynamically generated proxy class. Since meta-annotations are technically placed on the interface definition rather than the proxy implementation, proxy.getClass().isAnnotationPresent(MetaAnnotation.class) evaluates to false. Conversely, invoking .annotationType() returns the underlying annotation interface class, which accurately reflects the declared meta-annotations.

@TestComposite(
    target = com.example.ExtendedService.class,
    declaredProxy = true,
    nativeInterface = true
) public class ProxyIntrospectionDemo {
    public static void main(String[] args) throws Exception {
        Class<?> serviceClass = ExtendedService.class;
        AppProfile resolvedMeta = serviceClass.getAnnotation(AppProfile.class);
        
        Class<?> proxyClass = resolvedMeta.getClass();
        Class<?> actualInterface = resolvedMeta.annotationType();
        
        boolean existsOnProxy = proxyClass.isAnnotationPresent(AppProfile.class);
        boolean existsOnInterface = actualInterface.isAnnotationPresent(AppProfile.class);
        
        System.out.println("Found on Proxy Class: " + existsOnProxy);
        System.out.println("Found on Interface Class: " + existsOnInterface);
    }
}

The internal parsing pipeline solidifies this understanding. The AnnotationData construction triggers AnnotationParser.parseAnnotations(), which transforms bytecode attributes into a LinkedHashMap. Subsequently, annotationForMap() invokes Proxy.newProxyInstance(), binding the enterface to AnnotationInvocationHandler. The handler's invoke() method routes every field accessor to the map lookup, bypassing any physical storage for the annotation values themselves.

// Simplified representation of the internal invocation flow
final class AnnotationInvocationHandler implements InvocationHandler {
    private final Map<String, Object> metadataRegistry;
    private final Class<? extends Annotation> targetType;
    
    public Object invoke(Object proxy, Method method, Object[] args) {
        String methodName = method.getName();
        Class<?>[] paramTypes = method.getParameterTypes();
        
        if (paramTypes.length > 0) throw new AssertionError("Invalid signature");
        
        switch (methodName) {
            case "equals": return equalsImpl(args[0]);
            case "hashCode": return hashCodeImpl();
            case "toString": return toStringImpl();
            case "annotationType": return targetType;
            default: break;
        }
        
        // Direct map lookup mirrors the runtime resolution mechanism
        Object cachedValue = metadataRegistry.get(methodName);
        if (cachedValue == null) {
            throw new IncompleteAnnotationException(targetType, methodName);
        }
        return unwrapResult(cachedValue);
    }
}

Disabling JVM optimization flags allows visibility into these generated classes. Setting -Djdk.proxy.ProxyGenerator.saveGeneratedFiles=true dumps the bytecode. The resulting file resembles a standard dynamic dispatcher pattern, storing references to target methods and routing calls through a single InvocationHandler instance. Every annotation method delegation follows this exact pathway, confirming that runtime metadata access in Java fundamentally operates as a method dispatch layer over a pre-computed key-value structure.