search

Archinamon / android-gradle-aspectj

gradle plug-in adding supports of AspectJ into Android project
Apache License 2.0
363 stars 58 forks source link

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

Open mikekudzin opened 6 years ago

mikekudzin commented 6 years ago

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

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 commented 6 years ago

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

Archinamon commented 6 years ago

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

ab-helly commented 6 years ago

Is there any ETA on this?

johanflint commented 6 years ago

@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 commented 6 years ago

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

mijay commented 6 years ago

Are there any news on it?

KevinVlaanderen commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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!