Fix bytecode compliance check crash on project class references#5061
Merged
Conversation
The cn1:compliance-check goal (now bytecode-compliance) crashed when an invocation rewrite (String.split / replaceAll / replaceFirst) was applied to a class that referenced a sibling project class. ASM's CheckClassAdapter .verify was called without a ClassLoader, so SimpleVerifier fell back to Class.forName on the plugin classloader, which doesn't see user project classes, producing a TypeNotPresentException / ClassNotFoundException and failing the build. Pass a URLClassLoader that spans the project's output dir plus compile -scope dependency jars, and treat any remaining unresolvable types as a debug-level skip rather than a build failure — the verify is only a sanity check on our rewrite; the real compliance scan and the cloud build still catch genuine API misuse. Also migrates all internal POMs, archetypes, initializr templates, and the cn1lib lifecycle binding off the deprecated compliance-check alias to the new bytecode-compliance goal, so fresh initializr projects no longer print the deprecation warning. The alias remains for backward compatibility with older user projects, with a cleaned-up deprecation message. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
✅ Continuous Quality ReportTest & Coverage
Static Analysis
Generated automatically by the PR CI workflow. |
docs/demos pins to codenameone-maven-plugin 7.0.208 and scripts/skindesigner pins to 7.0.228; neither has the bytecode-compliance goal yet. Keep them on the compliance-check alias. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Collaborator
Author
|
Compared 116 screenshots: 116 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Contributor
Cloudflare Preview
|
Collaborator
Author
|
Compared 47 screenshots: 47 matched. |
Collaborator
Author
|
Compared 116 screenshots: 116 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
Collaborator
Author
|
Compared 116 screenshots: 116 matched. Benchmark Results
Build and Run Timing
Detailed Performance Metrics
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
BytecodeComplianceMojo.validateClasscrashed withTypeNotPresentException/ClassNotFoundExceptionwhenever an invocation rewrite was applied to a class that referenced a sibling project class. ASM'sCheckClassAdapter.verifywas called without aClassLoader, soSimpleVerifierfell back toClass.forNameon the plugin classloader (which doesn't see user project classes). The crash matches the "sometimes works, sometimes doesn't" reports: classes without rewrites or without sibling references pass; otherwise fail. Now we pass aURLClassLoaderspanning the project's output dir + compile-scope dep jars, and treat any remaining unresolvable type as a debug-level skip rather than a build failure — the verify is only a sanity check on our rewrite; the real compliance scan and the cloud build still catch genuine API misuse.cn1liblifecycle binding, and the bundled skill docs off the deprecatedcompliance-checkgoal name to the newbytecode-compliance. Fresh initializr projects no longer print the warning. TheComplianceCheckMojoalias remains for backward-compat with older user POMs, with a cleaned-up deprecation message (no more raw{@link ...}in the user-facing warning).Affected files: BytecodeComplianceMojo.java, ComplianceCheckMojo.java,
META-INF/plexus/components.xml, both archetypes, the five initializr POM templates, the bundled skill docs, and the various internal test/demo/script POMs.Test plan
mvn -o test -Dtest=BytecodeComplianceMojoTestpasses (all 4 rewrite tests, after null-projectguard so direct mojo instantiation still works in unit tests).mvn -o testis no worse than before (down from 7 → 3 errors; remaining 3 are pre-existingBindingAnnotationProcessorTestfailures about missinggetValidator()onNotifiableBindingsubclasses, unrelated to this change).grep -rn "<goal>compliance-check</goal>"on source POMs returns nothing.canopus-commonwithSwingTable→QPanereference +String.splitcallsite) builds cleanly.🤖 Generated with Claude Code