autonomousapps / autonomousapps/dependency-analysis-gradle-plugin
Incorrect advice for advanced reflection usage
- Dominant language
- Kotlin
- Stars
- 2.2k
- Forks
- 158
- Avg merge
- 16h 25m
- Merged PRs (30d)
- 46
Description
**Build scan link**
**Plugin version**
3.5.1
**Gradle version**
9.1.0
**JDK version**
17
**(Optional) Kotlin and Kotlin Gradle Plugin (KGP) version**
**(Optional) Android Gradle Plugin (AGP) version**
**(Optional) `reason` output for bugs relating to incorrect advice**
**Describe the bug**
When I use a framework like spring that relies on reflection to find optional dependencies and I declare them as implementation I'm advised to remove them rather to change to runtimeOnly.
This is the case when advanced reflection Patterns are used.
When code randomly manages to mention a class that might exist in another module and I declare the other module as implementation I'm advised to remove or change to runtimeOnly, rather to be advised to remove.
**To Reproduce**
Enable ignored test in #1614
**Expected behavior**
Well let's discuss :)
Maybe skipping cases where it is unclear what class is used when scanning for Class.forName i.e. by changing MethodAnalyzer to only record cases where the argument is "java-class-like".
And also maybe logging a warning?
I'm quite unsure if the current impl is as good as it gets, but wanted to write it down since I stumbled over it when debugging #1604.
**Additional context**
Filtering out these cases would reduce the amount of `explodedJars` with `reflectiveAccesses` in `SynthesizeDependenciesWorkAction::findReflectiveAccesses` by a lot in our case.
Since we are almost never using a plain string, and so aren't libraries we are using we would save around 50% of work when only having `reflectiveAccesses` that are actually "java-class-like"
Contributor guide
Research direction
Start with the ignored test referenced in #1614, then trace MethodAnalyzer and SynthesizeDependenciesWorkAction::findReflectiveAccesses. Compare how advanced reflection produces implementation-versus-runtimeOnly advice and identify the behavior the test should establish. Done means the team has agreed on the expected advice and the test reflects that decision.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, kotlin
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100