Introduction

backport175 has been designed to work in highly dynamic environment (such as load-time and runtime weaving for AOP). In environments like this the bytecode on disk is not the "current" one being executed. Since the bytecode has been transformed during the execution of the application. What this means is that annotations can have been added or removed.

We therefore need two things:

a way for the vendor/user to define a bytecode provider since the current one is not available on disk

an API for refreshing/updating the annotation reader, so we know that the annotations we have reflects the annotation in the latest bytecode

All these operation should be fully thread-safe, if not, then we have a bug.

Defining the bytecode provider

This is done by implementing the org.codehaus.backport175.reader.bytecode.spi.BytecodeProvider interface. This interface is a strategy with one single method you need to implement:

Registering the bytecode provider

The bytecode provider implementation class is registered in the org.codehaus.backport175.reader.bytecode.AnnotationReader class by invoking:

Refreshing the annotation reader

When a change to the bytecode has been made it is needed to refresh the annotation reader, so that it can pull the new bytecode from the BytecodeProvider, parse it and update the reader with the new information about the annotations.

This is done by invoking one of the refresh(..) methods in the org.codehaus.backport175.reader.bytecode.AnnotationReader class: