|
| 1 | +# OpenTelemetry Java Instrumentation |
| 2 | + |
| 3 | +## Testing |
| 4 | + |
| 5 | +Tests use AssertJ for assertions and JUnit 5 as the testing framework |
| 6 | + |
| 7 | +Test classes and methods should not be public |
| 8 | + |
| 9 | +When registering tests in gradle configurations, if using `val testName by registering(Test::class) {`... |
| 10 | +then you need to include `testClassesDirs` and `classpath` like so: |
| 11 | + |
| 12 | +``` |
| 13 | +val testExperimental by registering(Test::class) { |
| 14 | + testClassesDirs = sourceSets.test.get().output.classesDirs |
| 15 | + classpath = sourceSets.test.get().runtimeClasspath |
| 16 | + ... |
| 17 | +} |
| 18 | +``` |
| 19 | + |
| 20 | +## General Java guidelines |
| 21 | + |
| 22 | +* Always import classes when possible (i.e. don't use fully qualified class names in code). |
| 23 | + |
| 24 | +## Gradle CLI |
| 25 | + |
| 26 | +Never use the `--rerun-tasks` flag unless explicitly asked to use this option. |
| 27 | + |
| 28 | +Gradle automatically detects changes and re-runs tasks automatically when needed. Using `--rerun-tasks` |
| 29 | +is wasteful and slows down builds unnecessarily. |
| 30 | + |
| 31 | +## Throwing exceptions |
| 32 | + |
| 33 | +When writing instrumentation, you have to be really careful about throwing exceptions. For library |
| 34 | +instrumentations it might be acceptable, but in javaagent code you shouldn't throw exceptions |
| 35 | +(keep in mind that javaagent instrumentations sometimes use library instrumentations). |
| 36 | + |
| 37 | +In javaagent instrumentations we try not to break applications. If there are changes in the instrumented |
| 38 | +library that are not compatible with the instrumentation we disable the instrumentation instead of letting |
| 39 | +it fail. This is handled by muzzle. In javaagent instrumentations you should not fail if the methods |
| 40 | +that you need don't exist. |
| 41 | + |
| 42 | +## Javaagent Instrumentation |
| 43 | + |
| 44 | +### Java8BytecodeBridge |
| 45 | + |
| 46 | +When to use `Java8BytecodeBridge.currentContext()` vs `Context.current()` ? |
| 47 | + |
| 48 | +Using `Context.current()` is preferred. `Java8BytecodeBridge.currentContext()` is for using inside |
| 49 | +advice. We need this method because advice code is inlined in the instrumented method as it is. |
| 50 | +Since `Context.current()` is a static interface method it will cause a bytecode verification error |
| 51 | +when it is inserted into a pre 8 class. `Java8BytecodeBridge.currentContext()` is a regular class |
| 52 | +static method and can be used in any class version. |
0 commit comments