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:
If no bytecode provider is registered then a default one that uses
getResourceAsStream(), e.g. reads in the bytecode from disk, is used.
It is also possible to set a bytecode provider on a per class basis, which can be usefull in some circumstances.
Refer to the API documentation for more details.
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