I recently moved some projects to Java 7 (1.7.0_13) and subsequently get this error but only in isolated cases. It has taken some time to track down as it looked like it was a Proguard (4.8) issue, however it only occurs when running tests under Jacoco (0.6.2).
I have reduced the code to something small and replicable.
There are 2 maven projects, one is a "library" which just builds a JAR that is obfuscated using Proguard. The other project makes use of the JAR.
The library contains a class 'MyLib' which contains a private method init(long,Long) that the constructor calls. Proguard is set to obfuscate the internals, but keep the public class. Invoking that private method is where the error occurs.
The other project "test-app" uses the JAR that contains the obfuscated MyLib. It only contains a test class, where a test method instantiates the MyLib class.
If I don't run the test under Jacoco, no error is thrown.
If I remove the "dontoptimize" option to Proguard, no error is thrown - for this example only though. In my original project where this occurred first, it doesn't matter what I change in the proguard configuration. I always get the VerifyError when running tests that hit the equivalent private method.
If I change the init method so that it doesn't contain a long and a Long, then no error is thrown. Equally if I don't reference the Long inside the method, it all works.
To hit the problem, it is necessary to build "test-lib" under maven with the "install" target to get it into the local repo. Then either, build "test-app" under maven as well, or close the "test-lib" project in Eclipse and invoke the test class using the Jacoco runner in Eclipse. If the "test-lib" project is open in Eclipse when the unit test is invoked, then it obviously won't load the obfuscated class, and the test runs OK.
That's about as much as I can do at this stage.
This is my first post to github and I intended to add the ZIP of the 2 projects, but it appears that I can't do that. I could post the contents of the small source here, or email the ZIP to someone as per another ticket - I just didn't want to assume that that was OK.