-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
java.lang.ClassFormatError: Short length on BootstrapMethods in class file #462
Conversation
@nikhilnanivadekar could you please provide the original file |
@nikhilnanivadekar I think that @marchof was asking for class file. I'm able to reproduce this on my machine, so here is file - class.zip (in zip, because GitHub doesn't allow to attach class directly). |
@nikhilnanivadekar in the meantime as workaround you can exclude class from the instrumentation: diff --git i/unit-tests/pom.xml w/unit-tests/pom.xml
index a14a705..10c60ba 100755
--- i/unit-tests/pom.xml
+++ w/unit-tests/pom.xml
@@ -102,6 +102,12 @@
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco.plugin.version}</version>
+ <configuration>
+ <excludes>
+ <!-- https://github.com/jacoco/jacoco/issues/462 -->
+ <exclude>org.eclipse.collections.impl.collector.Collectors2Test</exclude>
+ </excludes>
+ </configuration>
</plugin> This does not affect coverage measurement of the main code since this is test file. |
@marchof if I'm not mistaken, seems that one bootstrap method is lost during instrumentation |
@Godin Interesting about this file is that there are >> 300 method references (which compiles to INVOKEDYNAMIC). I assume this is a ASM Bug. |
@Godin So we have another issue we would need an ASM release for. |
For the record: I tried JaCoCo with ASM from trunk, which includes fix for the mentioned bug, and it works without exclusion for Eclipse Collections. |
Any idea when will the bug fix be released? If it will be soon enough, I would rather wait for it and not add an exclusion. |
@nikhilnanivadekar Please let's discuss the separate issue on the mailing list. Unfortunatelly we have no insight in ASM project when they plan the next release. |
@nikhilnanivadekar so far we are not aware about plans of ASM developers regarding release. And would be better to not mix with other topics here. Thanks for your understanding. |
Updated my comment. Thanks! |
Ouch, didn't noticed Marc's answer. I'm going to ask in their mailing list about release, however without expectations - previously didn't get response on same question in bug tracker and there seems to be no activity since September. |
For the record - started thread about release in ASM mailing list: http://mail.ow2.org/wws/arc/asm/2016-12/msg00005.html |
A note to clarify relation of example given here with description of ASM bug: In presence of Serializable lambdas javac will generate method |
ASM 5.2 has been released, for upgrade we just need to wait its appearance in Maven Central repository. @marchof I'm wondering if we should add test for such case to prevent regressions in future, or just update dependency and hope that it won't regress? Could be noted that change in ASM wasn't explicitly covered by tests. 😉 WDYT? |
@Godin Of course we add a test -- if we're able to create a reproducer e.g. as a validation test! 😎 |
I chose to not add exact example with lambda deserialization as it depends on javac and its internals, and actually not so trivial to also trigger resizing in ASM. But added test that performs a bit of bytecode generation instead. As you can see - it fails before ASM upgrade and passes after. So @marchof could you please review this change? |
1df652e
to
08ef8a2
Compare
private static int run(final String className, final byte[] bytes) | ||
throws ClassNotFoundException, NoSuchMethodException, | ||
InvocationTargetException, IllegalAccessException { | ||
return (Integer) new ClassLoader() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can also use TargetLoader
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
* {@code java.lang.ClassFormatError: Short length on BootstrapMethods in class file} | ||
* during instrumentation. | ||
*/ | ||
public class AsmBugTest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We encountered several ASM bug in the past. So the test name looks a bit too generic for me. Also we tend to name our test cases like what is tested, not what is a bug. I would prefer something like BootstrapMethodReferenceTest
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@Godin Thank you very much for fixing this. |
@nikhilnanivadekar we can't tell you the exact date yet - there is no strict plan so far. And as was said in eclipse/eclipse-collections#166 (comment) : EclEmma Eclipse Plugin also needs an update, otherwise execution of tests with coverage in Eclipse using EclEmma will be failing without the current workaround. This update will take some time as we need to not only release JaCoCo, but also promote it as well as new ASM version thru Eclipse CQs into Orbit, followed by a first release of EclEmma under Eclipse umbrella. All in all my advice for you will be - no need to rush especially that workaround doesn't cause any troubles, a little of patience and stay tuned for announcements about releases 😉 |
For the record: here is a ticket about update for EclEmma - https://bugs.eclipse.org/bugs/show_bug.cgi?id=510059 |
Posted by @ nikhilnanivadekar :
I am trying to integrate JaCoCo for code coverage of Eclipse Collections
However the build fails with the below error:
java.lang.ClassFormatError: Short length on BootstrapMethods in class file org/eclipse/collections/impl/collector/Collectors2Test
The Collectors2Test.java is 1748 lines long with very small test methods. So, this should not cause any issues as they are well below 64KB method limit of Java.
If I break up this class in two separate files then the build goes through fine. Even after online research I am not able to find a way to fix the Travis build with JaCoCo integration and without splitting the Collectors2Test.java. The build goes through fine in IntelliJ.
The project is setup with Maven build and has surefire plugin.
argLine
is set in relevant modules where JaCoCo test coverage is run.GitHub repos and build links:
Eclipse Collections master
Repo
Travis build (passing)
JaCoCo integration with Collectors2Test split in two:
Repo
JaCoCo integration commit
Travis build (passing)
JaCoCo integration with Collectors2Test not split:
Repo
JaCoCo integration commit
Travis build (failing)
Steps to reproduce