|
| 1 | +# JCapsLock Analysis: Key Limitations |
| 2 | + |
| 3 | +JCapsLock provides static analysis of Java libraries and their capabilities, but users should understand several important constraints. |
| 4 | + |
| 5 | +## Primary Caveats |
| 6 | + |
| 7 | +**False Positives**: The analysis assumes all code paths execute, even conditional branches. For example, a method may contain an if statement where `Files.readAllBytes` is called if one of the method's parameters is true, potentially reporting capabilities that never actually occur. |
| 8 | + |
| 9 | +**Reflection Challenges**: Use of `java.lang.reflect` creates analysis difficulties. The tool flags reflection usage as its own capability to avoid missing potential capabilities without notification. In Java, reflection is commonly used by dependency injection frameworks (Spring, Guice) and serialization libraries (Jackson, Gson). |
| 10 | + |
| 11 | +**External Program Execution**: When code uses `Runtime.exec`, `ProcessBuilder`, or loads classes dynamically, the analysis cannot determine what capabilities these might have, so it is reported to the user as a capability of its own. |
| 12 | + |
| 13 | +**Unsafe Pointer Operations**: Although typically used simply, `sun.misc.Unsafe` theoretically enables arbitrary behavior. The tool treats this as a reportable capability. |
| 14 | + |
| 15 | +**Dynamic Class Loading**: Classes loaded via `Class.forName` or custom classloaders cannot be fully analyzed, so dynamic loading is flagged as a capability. |
| 16 | + |
| 17 | +**Native Code**: JCapsLock cannot analyze native code called via JNI or JNA, reporting these as `CGO` capabilities. |
| 18 | + |
| 19 | +## Maven-Specific Considerations |
| 20 | + |
| 21 | +**Dependency Resolution**: Run JCapsLock from your project directory to ensure dependency resolution matches your Maven build. Active profiles and dependency mediation affect which versions are analyzed. |
| 22 | + |
| 23 | +**Optional Dependencies**: Libraries often declare optional dependencies for features you may not use. Use `-Dcapslock.includeOptional=false` to exclude them from analysis. |
| 24 | + |
| 25 | +## Runtime Enforcement (First Experiments) |
| 26 | + |
| 27 | +JCapsLock includes an experimental runtime agent that can monitor and block capabilities at runtime. While functional, there are unresolved issues being actively worked on: |
| 28 | + |
| 29 | +**Performance Impact**: The instrumentation adds overhead to capability-checked methods. The impact varies depending on how frequently these methods are called. |
| 30 | + |
| 31 | +**Multithreading**: Execution paths can escape enforcement checks in multithreaded scenarios. Thread handoffs and asynchronous callbacks may not be fully traced. |
| 32 | + |
| 33 | +See [agent/README.md](../agent/README.md) for current usage and limitations. |
| 34 | + |
| 35 | +## See Also |
| 36 | + |
| 37 | +- [Go Capslock Caveats](https://github.com/google/capslock/blob/main/docs/caveats.md) - Caveats for the original Go implementation |
0 commit comments