New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(When AGP 3.0 is released) Java 8 and assume desugar for android, or target Java 7? #10
Comments
Been tinkering with this more. Copying over my notes shared elsewhere:
The lack of being able to set a meaningful breakpoint seems pretty bad. Easy to trace back, once you hit one, but it's pretty much impossible to find the generated class that corresponds to a lambda without a breakpoint farther down the line. In light of that, I'm leaning toward not doing retrolambda. For example: the following snippet @Override
public final void onError(Throwable e) {
if (!isDisposed()) {
dispose();
try {
onError.accept(e); // Where onError was a method reference of a SingleObserver's onError
} catch (Exception e1) {
Exceptions.throwIfFatal(e1);
RxJavaPlugins.onError(new CompositeException(e, e1));
}
}
} corresponds to this in the debugger when decompiled, where this is the actual backing implementation of the above // $FF: synthetic class
final class AutoDispose$AutoDisposingSingleObserverCreator$$Lambda$4 implements Consumer {
private final SingleObserver arg$1;
private AutoDispose$AutoDisposingSingleObserverCreator$$Lambda$4(SingleObserver var1) {
this.arg$1 = var1;
}
@Hidden
public void accept(Object var1) {
this.arg$1.onError((Throwable)var1);
}
public static Consumer lambdaFactory$(SingleObserver var0) {
return new AutoDispose$AutoDisposingSingleObserverCreator$$Lambda$4(var0);
}
} Thoughts @tonycosentini @vinc3m1 @LukeStClair? |
We should prioritize debugging and using this over development IMO. It's not a huge thing - Java 7 isn't a big deal to me. |
With desugar coming to the android toolchain, should we move to Java 8 and assume people will use desugar? |
I would wait until stable release, but after that sure. |
What benefit does it give the library? It seems like for consumers it adds a bit of friction for using this, no? |
It makes the library easier to read/write in by using the new syntax features. From a java library distribution standpoint - everyone writing a pure java project these days should really be on Java 8. On Android, with desugar, it should be zero friction since it all gets done at dexing. |
It's really not in a stable place yet though, right? At least in trying to
use it myself, I had to turn it off eventually because of all the issues I
ran into. It also requires alpha plugins to work correctly, no?
…On Mon, May 1, 2017 at 11:01 AM Zac Sweers ***@***.***> wrote:
It makes the library easier to read/write in by using the new syntax
features. From a java library distribution standpoint - everyone writing a
pure java project these days should really be on Java 8. On Android, with
desugar, it should be zero friction since it all gets done at dexing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABONuAC1kl9mvQcQAy1MNBtfVyyXO52Uks5r1h3xgaJpZM4LUr5Y>
.
|
I should have clarified - *when android gradle plugin 2.4 stable is released, not immediately. |
I'm not sure if you can assume that everyone will upgrade to 2.4 stable as soon as it is released. What is the downside of using Retrolambda until better adoption of newer tools? |
In testing with this, I found that consuming retrolambda'd libraries in Java 7 projects (retrolambda'd or not) actually added quite a bit of friction. Due to how the weaving works, you get no sources (only decompiled class files), and trying to step through them in the debugger is pretty hit or miss. Not to mention you can't actually open said generated classes due to not having sources, so you can't just go open them and set a breakpoint manually either :|. The desugar approach they're taking with the gradle plugin actually works around this by treating the entire project as java 8 until you compile, at which point it will also desugar any Java 8-targeting libraries compiled with it. |
Another potential benefit: LifecycleScopeProvider could be moved to a separate (optional) artifact if we support default methods. It could just extend ScopeProvider and the default This works fine for android gradle projects, but could incur a nontrivial cost for buck/bazel builds where incremental compilation can't work some magic. |
Opened an issue on bazel to better understand how they avoid clean build churn - bazelbuild/bazel#4186 |
Closing in favor of #198 |
Need to make a call on this based on our integration and see how it fairs using this in Java 7 source.
The text was updated successfully, but these errors were encountered: