java.lang.ClassNotFoundException when plugin added to a project with JavaVersion.VERSION_1_8

[mikekudzin]

Hi! I encountered the following issue with projects with java 8 support. Do the following steps:

• Start new project (File->New->New Project)
• Add compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } to the android { } section of the app's module
• Run the app, check it works
• Clean
• Add classpath 'com.archinamon:android-gradle-aspectj:3.2.0' to the top level build.gradle and apply plugin: 'com.archinamon.aspectj' to the app level ** No aspects where added at all, nor annotated, no .aj either, just plugin
• Run the app (you might need to run clean-build 1 or 2 times)

Result. App crashes with an exception on start:

Caused by: java.lang.ClassNotFoundException: Didn't find class "com.demo.myapplication.MainActivity" on path: DexPathList[[zip file "/data/app/com.demo.myapplication-1/base.apk"],nativeLibraryDirectories=[/data/app/com.demo.myapplication-1/lib/x86, /system/lib, /vendor/lib]] at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56) at java.lang.ClassLoader.loadClass(ClassLoader.java:380)

Console output: `> Task :app:transformClassesWithStackFramesFixerForDebug :app:transformClassesWithStackFramesFixerForDebug spend 741ms

Task :app:transformClassesWithDesugarForDebug :app:transformClassesWithDesugarForDebug spend 2073ms

Task :app:transformClassesWithAspectjForDebug ---------- Starting augmentation with AspectJ transformer ---------- Ajc classpath doesn't has needed runtime environment ---------- Exit AspectJ transformer w/o processing ---------- :app:transformClassesWithAspectjForDebug spend 12ms

Task :app:transformClassesWithDexBuilderForDebug :app:transformClassesWithDexBuilderForDebug spend 107ms `

[mikekudzin]

It looks this issue related to https://github.com/Archinamon/android-gradle-aspectj/issues/71

[Archinamon]

Hi! Thanks for report! This issue occurs due to plugin incompatibility with java 8. Will be fixed soon in 3.3.0 :)

[ab-helly]

Is there any ETA on this?

[johanflint]

@Archinamon, do you have any idea when 3.3.0 will be shipped? We would love to be able to upgrade our app to Java 8 and this issue is blocking for us.

[mmehmetAliIzci]

Yeah, we also want to update to Java 8 but we can't because of this issue.

[mijay]

Are there any news on it?

[KevinVlaanderen]

Hi @Archinamon , This issue is currently a major blocker for us, so we'd love to make progress on this story. Do you feel this issue is solvable in the short term?

[jdvp]

I am also having this issue. Has this always happened or can I revert to an older version? Just wondering because I had used this for a previous project that was using Java 8 and had no issues (unfortunately I no longer have access to the source code for that project so I can't check what settings we were using)

EDIT: as a workaround, I was able to fix my project by using retrolambda for Java 8 support rather than the native toolchain. This won't work in all cases depending on which Java 8 features you want but it works well enough for me, just as a heads up

[OllisGit]

@jdvp please give us some more details how do you implement the workaround with retrolambda. @Archinamon please so nice and give us some information about your analyse, maybe some from the "community" could support you to fix it. Thx, in advance Olli

[jdvp]

@OllisGit Basically just use retrolambda for certain java 8 things instead of the built in AS support. Setup instructions can be found here : https://github.com/evant/gradle-retrolambda

Basically all you really need to do is include the dependency at the top level gradle and apply the plugin in the module level gradle files

[sheelaknaik]

@Archinamon can you please let me know when would the newer version be available? We are facing issues due to inclusion of Java 8 features.

[JustinTullgren]

@Archinamon are you willing to accept a PR against this issue? If so I just have one question on where the best place to put the fix would be. The issue appears to be that the aspectj runtime isn't on the classpath for your AspectJWeaver so the transformer does not invoke the weave. When no weave happens the files aren't output at the end of the transform which is why the classes aren't in the resulting apk and we get the NoClassDefError.

I was going to add the compile class path to the weaver during the AspectJTransform#setupVariant method but not sure if thats the best place?

Thoughts?

[JustinTullgren]

After looking at it again it looks like the AJ runtime is there but do to the transform API the name of the jar file doesn't match test. The name is available in the inputs data however. If we can come up with a better test or another piece of data to test to ensure the AJ runtime is there that will be more robust and a little safer I think than changing how the variant is already configured.

[JustinTullgren]

Hi @Archinamon we have a potential fix for this. We skip the transform api and just piggy back on the javac task. The transform api messes with the bytecode of compiled aspects and we have no control over it.

Is there a particular reason you went with the transform api over just using your existing compile task?

[Archinamon]

Hi Justin! Transform API is only way to operate over compiled aar/jar libraries. I think to make a variance to be able to skip this way and just replace javac with ajc. Already tested this way in unit tests with new aspectj-junit sub-plugin.

Maybe this will be a good point to work on?

[JustinTullgren]

Hi @Archinamon,

Sorry I don't completely follow your thought. Do you mean you cannot weave compiled aspects from JarA into JarB/aarB?

Also if every variant (product flavor + build type, etc) gets run with its own javac task wouldn't the AJcompile task which finalizes the javac task work just fine if it replaced the javac task output?

Thanks!