NoClassDefFoundError sometimes. #37
Comments
|
Which versions of the Gradle plugin and Retrolambda are you using? Based on the error message, the containing class was processed with Retrolambda and it should have written the Lambda$1 class, but for some reason the Lambda$1 class was removed after that. Sounds like something related to incremental compilation. @evant can you have a look at this? |
|
I'm using gradle-retrolambda of 2.4.0 with gradle plugin 0.13.3. |
|
This very well may be an issue with incremental building in the gradle plugin. Try seeing if you can consistently reproduce it by changes some file(s). Then run |
|
I can confirm this issue. It always showed up in the same spot using a lambda as a comparator with Collections.sort . a clean would always take care of it. I saw this on 1.x and still see it on 2.x of the gradle plugin. Eventually I removed that one lambda and I haven't seen the problem since |
|
@dbachelder You said you saw it on 1.x? That's strange, because incremental builds wasn't added until |
|
It is repeatedly reproduces when I checkout some other branch, such is 2-3 commits ahead/behind, so very few files are changed. So here is my retrolambda output. |
|
It occurred to me to think about that what kind of a mechanism Gradle or Javac might be using for detecting that which files have changed. Reading the source would be best to find out the answer, but one possibility is that it looks at the SourceFile entries in the bytecode, which the lambda classes are missing. @pepyakin Can you try reproducing this issue with a modified version of Retrolambda? First find out steps that reproduces it reliably for PhoneCodeUtils$$Lambda$1. Then do the following change to Retrolambda, If that fixes it or if the error message changes to complain about some other files, then maybe we're onto something. |
|
I can't reproduce issue anymore. I tried several options like changing different source and resources, checkout "distant" commits and so on, but bad luck. |
|
I can confirm this issue, it only occurs here (using RxJava): |
|
@wkarl Good. Can you try if using a modified version of Retrolambda fixes it, as I explained earlier? (Of course change the source file name to match your file.) Or can you create a SSCCE? |
|
Sorry for the late reply. After a clean it worked again and I wasn't able to reproduce the issue ever since... if it resurfaces I will try the modified version! |
|
@orfjackal So I've reproduced this issue with modified version and it makes no difference. |
|
OK, so at least that fix won't work. More debugging is needed, maybe even digging into the code of Gradle's incremental compiler. If you manage to determine steps for reproducing this issue reliably, please post it here. |
|
I just found two commits such when I switch back and forth between them I'm expierence this issue, so I can't call it "reliable". |
|
Any news on that topic? e.g. solved with a newer version of e.g gradle? |
|
I've seen this issue repeatedly as well. What's interesting is that it only seems to affect certain classes; put a lambda anywhere in one, and it will eventually run into this issue, repeatedly, through multiple cleans. But most classes don't run into it. I'll try running some debugging on it next time I run into this, to figure out what is different about these classes in particular. |
|
I am experiencing this as well and can confirm that it is resolved when I perform a 'gradle clean' and rebuild. I will try to isolate a minimal reproducible example. |
|
Hi all, I still get this error as well, by performing "gradle clean" and rebuild it seems to clear the problem but is there any fix coming ? Thanks |
|
I'm seeing this as well - exactly as described by others. Usually crops up in the same place in the same class. Anecdotally, I also have been noticing that sometimes the app doesn't reflect my code changes, which drives me crazy figuring out why things weren't working for a while, but then it magically starts working as it (presumably) finally picks up my new code. This has only happened in recent weeks and is the first time my dev experience has been anything other than rock solid. |
|
I'm also face with the problem only on certain classes and I can't figure out on what depends this error. It appears random. I use RxJava and retrofit, but I think that most of retrolambda users use these libraries. |
|
I had this problem today as well and can confirm that rebuilding/cleaning fixed the problem. I'm using AndroidStudio 1.1 Beta 4 with Gradle 1.0.0, RxJava using gradle dependencies which references the following code in my onCreate method: closeButton.setOnClickListener(v -> finish()); |
|
Same problem here. Seems to be something related with Android Gradle plugin. I was using 1.1.0 and was facing the crash. After downgrading to 1.0.1, the crash went away. Maybe something new in the plugin is causing this? I'm using the gradle plugin 2.5.0 with retrolambda 1.8.1 |
|
Looks like I have a deterministic way of reproducing this issue, have been reproducing 10 times in a row now by the following scenario. I have two classes (ClassA and ClassB). ClassB contains lambdas, and ClassA is the one that allocates ClassB. So, it naturally enough does not rebuild ClassB when there are no changes in ClassB, but why does it remove the lambda-class of ClassB when the one that allocates ClassB is changed? |
|
@osunnarvik Your replication is correct. The conflict might be with Dex/pre-Dexing. For the time: you can use proguard to catch that in the compilation and see if you need a clean build |
|
@osunnarvik You are right. I did reproduce this issue by following the scenario you described. I'm facing the same problem as well. It only happens in one place. Clean and rebuild fix the problem. I'm also using RxJava and retrofit. |
|
Anyone running into this issue, can you try updating to 3.0.0 and setting incremental to false? If that fixes it then it's definitely and issue in the gradle plugin. |
|
Also, @osunnarvik or anyone else, mind posting a sample project that has the issue as you describe it? I tried to reproduce it with my own ClassA and ClassB myself, but couldn't. There might be something more subtle here that I'm missing. |
|
I have the same problem here using the version 2.5.0 |
|
I had same problem as @osayilgan: works in local machine but fails in Travis. Problem was So maybe there's some issue with support-v4:22.1.0 Also checked with 22.1.1 and problem still occurs. |
|
I am seeing this problem after upgrading the android support libs from 22.0 to 22.1. It will compile fine if I run I'm running /cc @evant It looks like retrolambda is able to build a few files until it reaches the first one that subclasses a |
|
@shekibobo It looks like you are running into evant/gradle-retrolambda#105, unlike this issue, it can be consistently reproduced and has something to do with the latests support library. I have a workaround listed there that seems to fix it. |
|
I encountered the error once again. Here is the source code (inside a method in a Activity): And this is the decompiled source code under the intermediates folder produced with the help of gradle-retrolambda: the correct which should have been produced is: @orfjackal could you please check? |
|
@Diolor, the replacement of |
|
We started hitting this issue recently as well. Somehow it's getting more frequent now. I don't think this has anything to do with the support library (at least in our case), as we're reproducing this problem in a pure-java library. |
|
I found |
It said sometimes fails in evant/gradle-retrolambda#105. Right workaround: run |
|
ypresto's workaround worked for my situation for my CI build. Thanks for that. |
|
Not sure this is relevant but the coincidence is to strong to ignore it. I got the same problem (java.lang.NoClassDefFoundError: XXX$$Lambda$) and I noticed it always happen on the same class A after I modified a class B. A and B are not related, except that B's name is a suffix of A's name. Recently I got the exact same problem with another pair of class, and guess what, the naming is similar, one class name is a suffix of the other class name. As a workaround I renamed my classes so one is not a suffix of the other. Edit: I confirm this is related to class names, I created two small classes |
|
@clemp6r Thanks! I think that lead me right to the issue. https://github.com/evant/gradle-retrolambda/blob/master/src/main/groovy/me/tatarka/RetrolambdaTask.groovy#L138 the regex for deleting the related lambda isn't quite right and deletes any lambdas with the same suffix. |
|
Nice! |
|
Awesome! This will be a great fix |
|
Fantastic! Thank you for discovering that. I hope this fixes it. A long, long running bug indeed! |
|
wow!!! thank you!!! i'll try that fix for incremental build after it is released. 🎉 🎉 |
|
Fixed in |
|
Brilliant!! Thanks for the fix! |
|
@clemp6r super! Good job |
|
Nice sleuthing @clemp6r! This fix needs a virtual celebration. |
|
My bad, I had to upgrade the gradle plugin :O Thanks for the solution! |
|
i've just encountered this exact same issue. i'm using retrolambda 3.6.0, gradle 2.3.0, compiled with SDK25, running on device with SDK17 seems like the issue has crept back even though it was fixed in |
|
@monemihir can you open a new issue on gradle-retrolambda? I wonder if it's related to evant/gradle-retrolambda@301d176 |
|
Same here! @monemihir |
|
Having the same problem. Running an app on an Android device running Marshmallow & below causes NoClassDefFoundError crashes all over. |
|
If you are using multiDex ... I solved it in this way: In your manifest ... If you do not override the Application class then: If you override it, make sure that you are not extending from Application, instead you should extend from MultiDexApplication and in your manifest should be something like this : |
and others
I have strange issue for a quite some time, sometimes when I build my app, following exception occur.
This is first occurrence of lambda on code path, so I think that either retrolambda didn't run or it's result classes not included in final dex. Cleaning the project usually makes the deal.
But it seems this happens more frequently eventually.
I tend to think it is somehow related to incremental building, but not sure.
The text was updated successfully, but these errors were encountered: