AEM 6.1 & Java 1.8 Bytecode Verification Error - Constructor must call super() or this() before return

[timlwhite]

Hello -

 Using Java 1.8u77, and the uber-jar 6.1.0-SP1, when trying to compile, I am seeing this error which is preventing the code from compiling.

at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) at org.codehaus.classworlds.Launcher.main(Launcher.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution generate-scr-scrdescriptor of goal org.apache.felix:maven-scr-plugin:1.20.0:scr failed: An API incompatibility was encountered while executing org.apache.felix:maven-scr-plugin:1.20.0:scr: java.lang.VerifyError: Constructor must call super() or this() before return Exception Details: Location: org/apache/sling/api/servlets/SlingSafeMethodsServlet.<init>()V @1: return Reason: Error exists in the bytecode Bytecode: 0x0000000: 2ab1

Based on what I can tell, this appears to be because the Java 1.8 Verifier is more strict, and there is code in the 6.1 API that won't pass verification.

When I try and use -noverify, I am getting a lot of other errors instead.

How are folks getting around this?

Thank you!

Tim

[smacdonald2008]

As a test - try using JDK 7 - lets see if its a JDK issue. Let us know what happens. 

[timlwhite]

Yes, it compiles just fine under 1.7:

[INFO] --- maven-sling-plugin:2.1.0:install (install-bundle) @ ewcm.global.core --- [INFO] Installing Bundle ewcm.global.core(C:\Projects\EWCM_Projects\ewcm\core\target\ewcm.global.core-1.0.51-SNAPSHOT.jar) to http://localhost:4502/crx/repository/crx.default/apps/ewcm/install/ via PUT [INFO] Bundle installed [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 45.529 s [INFO] Finished at: 2016-04-13T15:15:49-06:00 [INFO] Final Memory: 26M/226M [INFO] ------------------------------------------------------------------------

[timlwhite]

This appears to be an issue with the AEM 6.1 Obfuscated Uber Jar.  The obfuscator appears to have removed various bits and pieces from the bytecode that the Java 1.8 compiler is requiring to be there.

I got the unobfuscated Uber Jar from AEM support, and after much Maven wrangling, was able to compile against it without these errors.  Unfortunately, using this jar means you have to run your own Maven repo, or manually install the Uber Jar in the Maven repo on every developer machine and build server.

Various articles indicate that obfucators can break Java Bytecode Verification.

From http://www.excelsior-usa.com/articles/java-obfuscators.html :

• Overobfuscated classes may not pass stricter bytecode verification anticipated in future JVM implementations. [i.e. 1.8]

So the solution appears to be to have Adobe adjust the settings on the obfuscator they are using on the Uber Jar so that 1.8 will compile against it.

Thanks!

Tim

[smacdonald2008 · Accepted solution]

[Workaround]:- 

As a test - try using JDK 7 - lets see if its a JDK issue. Let us know what happens. 

Please open a ticket on this. If there is a bug - you need to report this to support so it can move up the chain to Eng team so it can be fixed. 

https://helpx.adobe.com/marketing-cloud/contact-support.html

[paul_bjorkstran]

smacdonald2008 wrote...

[Workaround]:- 

As a test - try using JDK 7 - lets see if its a JDK issue. Let us know what happens. 

Please open a ticket on this. If there is a bug - you need to report this to support so it can move up the chain to Eng team so it can be fixed. 

https://helpx.adobe.com/marketing-cloud/contact-support.html

TBH, that isn't really a reasonable approach. The documentation says that Java 8 is supported (https://docs.adobe.com/docs/en/aem/6-1/deploy/technical-requirements.html#Java Virtual Machines), but when you don't provide the dependency library upon which to compile under Java 8, you are adding a footnote. I don't see any such footnote saying anything to that effect. It is disheartening and disappointing that the only recourse is to downgrade.

[stevec2515680]

I will check to see if a fix has been made since this post was created.

[paul_bjorkstran]

I appreciate the help, Steve. Hopefully you are able to look further than the public dependencies in Adobe's Nexus repo. I tested against all 6.1 variants (6.1.0, 6.1.0-SP1, and 6.1.0-SP1-B0001) and all fail with the same verification error.

Saying you are Java 8 compatible and not letting developers use Java 8 is like Microsoft saying "Excel runs on Windows 10, but if you want to use formulas, you need to use windows XP". I do understand that you can get the unobfuscated jar, but my current client does not have it in their repo. I will be seeing if they would be willing to ask for the unobfuscated jar.

In the meantime, I will be using the ugly workaround of using the 6.0 version of the uber-jar: 

<dependency> <groupId>com.adobe.aem</groupId> <artifactId>aem-api</artifactId> <version>6.0.0.1</version> <scope>provided</scope> </dependency>

[timlwhite]

FYI, when I opened a ticket with support on this issue, their reply was to use the unobfuscated jar you can only get by opening a support ticket (and then you have to hack Maven to load it locally instead of trying to download it).

As for using the obfuscated jar, this was their reply:

~~Ticket Id: 89821

Hi Tim,
Unfortunately this is a known issue with the obfuscated api jar:
https://docs.adobe.com/docs/en/aem/6-2/develop/dev-tools/ht-projects-maven.html#You%20mentioned%20an....

There really is no simple solution to this and the Adobe engineering team is aware of the issue already.

Unfortunately, the problem is not due to the obsfucation level, it is because scr xml files cannot be generated.

Please let us know if you have any questions or concerns on this or if we can close out the ticket.