From 169f99554da8c178142877c1f956368dc5b246db Mon Sep 17 00:00:00 2001 From: Mateusz Rzeszutek Date: Tue, 27 Apr 2021 22:04:18 +0200 Subject: [PATCH] Minor improvement in the writing-instrumentation-module.md doc (#2871) --- docs/contributing/writing-instrumentation-module.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/contributing/writing-instrumentation-module.md b/docs/contributing/writing-instrumentation-module.md index 23f0e1510c..6560dbb35c 100644 --- a/docs/contributing/writing-instrumentation-module.md +++ b/docs/contributing/writing-instrumentation-module.md @@ -195,9 +195,12 @@ Advice classes are not really "classes", they're raw pieces of code that will be the instrumented library class files. You should not treat them as ordinary, plain Java classes - unfortunately many standard practices do not apply to them: +* if they're inner classes they MUST be static; * they MUST only contain static methods; * they MUST NOT contain any state (fields) whatsoever - static constants included! Only the advice methods' content is copied to the instrumented code, the constants are not; +* inner advice classes defined in an `InstrumentationModule` or a `TypeInstrumentation` MUST NOT use + anything from the outer class (loggers, constants, etc); * reusing code by extracting a common method and/or parent class will most likely not work properly: instead you can create additional helper classes to store any reusable code; * they SHOULD NOT contain any methods other than `@Advice`-annotated method.