Expand my Community achievements bar.

SOLVED

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

Avatar

Level 3

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

1 Accepted Solution

Avatar

Correct answer by
Level 10

[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

View solution in original post

8 Replies

Avatar

Level 10

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

Avatar

Level 3

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] ------------------------------------------------------------------------

Avatar

Level 3

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

Avatar

Correct answer by
Level 10

[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

Avatar

Level 2

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.

Avatar

Level 4

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

Avatar

Level 2

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>

Avatar

Level 3

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.