Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
VerifyError using Java 7 & Eclipse Juno #543
What steps will reproduce the problem?
What is the expected output? What do you see instead?
What version of the product are you using? On what operating system?
I have also tried edge build 0.11.7 2013-03-26 01:46 UTC with same result.
Please provide any additional information below.
The test passes when compiling and running from the Maven command line (both Oracle JDK6 & Oracle JDK7).
The problem seems to relate be the inter-play between the Eclipse Java 7 compiler and Lombok.
Err, that's actually probably relatively time-consuming to solve. I'm going to push v0.11.8 out with this bug open. I am going to mark it as accepted though, because while I haven't personally verified it (that would involve downloading a bunch of tools), the bug reporter has obviously put in all due care.
It could be three different things:
grant.forrester.mobiqa: The brand new release (0.11.8) has a new feature in it (not even the latest edge has this, I made it to help this bug report): If you add the 'lombok.disablePostCompiler=true' option to your eclipse.ini ( -Dlombok.disablePostCompiler=true immediately before -javaagent:lombok.jar in your eclipse.ini), then post compilation will be disabled. This means that @ SneakyThrows will actually compile down to Lombok.sneakyThrows and thus you'd need lombok.jar at runtime which is bad, but, if that solves this bug we now know it is either due to ASM or due to a bug in one of our rewriters. For extra credit, try -Dlombok.debugAsmOnly=true and see what happens now - this will cycle the code through ASM but actually not make any changes, so, if you get a buggy classfile with only that switch, it's an ASM issue which probably means we need to update that. If that is the issue, could you attach the class file produced when you use -Dlombok.disablePostCompiler=true, i.e., the one that DOES work? That gives us a specific class file to experiment with.
thanks a bunch!
NB: Download is here: https://projectlombok.org/download.html - and 0.11.8 should be available from maven central in a few hours.
***** WARNING: Before marking this bug as verified, remove the debugAsmOnly code throughout the codebase! *****
I do confirm that adding -Dlombok.disablePostCompiler=true in eclipse.ini just before -javaagent:lombok.jar DOES solve the issue.
This issue is actually not related to JRebel and attached is a very simple class that reproduces the issue.
I hope this will help and thanks for your work !
In case you have ideas for a blind fix, we can try a snapshot build !
Eeeeeesh, okay, this is basically about how re-analysing class files, at least with objectweb's ASM, is basically impossible now. To do anything beyong the trivial, you need to muck about with inserting frames into the class file, but ASM's handling of this seems kinda weird. If you let ASM sort it all out, you MUST provide a method that determines, given 2 classnames in string form, the classname of the common supertype. We thought you could just return 'Object' safely here but that is what is triggering this bug.
To avoid this, we have to do our own frame calculation but the code we would prefer to generate is incompatible with that idea, because the compiler cannot handle opcodes following an ATHROW.
Fortunately, we do have a fix which is reasonable:
proper usage of Lombok.sneakyThrow, which is:
will work fine, but improper usage of Lombok.sneakyThrow, which is:
will no longer get the call expunged from the class file. Meaning, you would need lombok.jar on the classpath.
We emit a warning in javac, but we don't do anything in eclipse because we can't report errors reliably at the point where we realize this is happening (or we have to add some relatively significant overhead to ALL eclipse processing by scanning for calls to Lombok.sneakyThrow which doesn't seem to be worth it).
We've got this in a local branch now and will probably commit it as the fix for this issue if we can't think of something better.
More generally, I hope people aren't making big plans for the post processor API of lombok itself, because, basically, you're going to have to do your own frame calculation which is pretty much undoable. Presumably there's a reason ASM can't actually pull it off without a 'common type' oracle.
NB: One alternative is to actually implement the 'what is the common supertype' class properly for each compiler environment. After all, the compiler would know what the common supertype is of any 2 given types present in a file it just compiled. We don't need to go that far just for sneakyThrows fortunately.
The changelog for release 0.12 mentions
However, one of our developers has tried the new version and noticed that it now works without adding -Dlombok.disablePostCompiler=true in eclipse.ini.
Thanks a lot and let's not forget this beer @ Devoxx 2013 !
Awesome. I'm googling for a different issue, randomly stumble on this, read through this because it's on 'accepted', and finally realize that we should have marked this bug as 'verified' earlier. My mistake. verified now :0