-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve condy (constant dynamic) support #139
Conversation
Codecov Report
@@ Coverage Diff @@
## master #139 +/- ##
============================================
+ Coverage 44.08% 44.12% +0.04%
- Complexity 2521 2527 +6
============================================
Files 362 362
Lines 16322 16327 +5
Branches 2126 2127 +1
============================================
+ Hits 7195 7205 +10
+ Misses 8398 8394 -4
+ Partials 729 728 -1
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Hello @kriegaex, Thank you for you PR! You'll need update this PR with some kind of test, otherwise, this is a regression waiting to happen. It could be as simple as parsing a class file that fails without applying the "main" side for the PR. The test should reflect what you say happens, namely:
Take notice that Codecov commented that coverage has decreased due to this PR not being tested:
In fact, that is often what I do to validate a PR:
Thank you again for helping out 😄 |
So, instead of being happy that someone provides a PR at all after me having begged the contributors for a bugfix, and writing a test by yourself, now the PR I was asked to contribute before is not good enough still, and I should provide a test, too? That is quite an interesting experience with this project. What exactly do maintainers do around here? Simply wait for users to do everything? Actually, I do have a test, but it requires JaCoCo in my Maven project. I checked whether you have a Maven Invoker test suite, but you do not. So there is no easy way to provide a test without digging into BCEL's intestines and writing a separate test, similar to the ones you already have with extra precompiled class files that can be processed by BCEL. I do not have the cycles for that. Actually, I only wanted to fix a problem in AspectJ, asking the BCEL team for help. I got none, so I had to fix it myself in AspectJ. I was even nice enough to provide a bugfix for the upstream project, and now that is not good enough. Uh-huh. |
Fixes https://issues.apache.org/jira/browse/BCEL-362. There was a problem when processing JaCoCo-instrumented code with BCEL, e.g. when passing it through example class JasminVisitor, causing java.lang.ClassCastException: class org.apache.bcel.classfile.ConstantMethodref cannot be cast to class org.apache.bcel.classfile.ConstantClass (org.apache.bcel.classfile.ConstantMethodref and org.apache.bcel.classfile.ConstantClass are in unnamed module of loader 'app') at org.apache.bcel.generic.ConstantPoolGen.<init>(ConstantPoolGen.java:153) at org.apache.bcel.generic.ConstantPoolGen.<init>(ConstantPoolGen.java:211) at de.example.JasminVisitor.<init>(JasminVisitor.java:70)
FWIW, I added a test case - not with the goal to increase coverage but to prevent future regressions. Reverse the order of the two commits, and the test before the fix will fail. |
Instead, we document contributions in `changes.xml` which I'll update after I merge PR.
Fixes https://issues.apache.org/jira/browse/BCEL-362.
There was a problem when processing JaCoCo-instrumented code with BCEL, e.g. when passing it through example class
JasminVisitor
, causing