(When AGP 3.0 is released) Java 8 and assume desugar for android, or target Java 7?

[uber]

(When AGP 3.0 is released) Java 8 and assume desugar for android, or target Java 7?

[ZacSweers]

Been tinkering with this more. Copying over my notes shared elsewhere:

The generated lambdas do have to be decompiled by the IDE in the debugger, but they're pretty simple and easy to read once you understand the structure. Still not as nice as stepping through source though. Regular sources do show up in java 8 syntax. You even get the option to set a breakpoint on the lambda innards like normal java 8 code, except those breakpoints never actually get hit (which seems like a big minus).

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 onError Consumer object in byte code:

// $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?

[tonycosentini]

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.

[ZacSweers]

With desugar coming to the android toolchain, should we move to Java 8 and assume people will use desugar?

[vinc3m1]

I would wait until stable release, but after that sure.

[tonycosentini]

What benefit does it give the library?

It seems like for consumers it adds a bit of friction for using this, no?

[ZacSweers]

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.

[LukeStClair]

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

[ZacSweers]

I should have clarified - *when android gradle plugin 2.4 stable is released, not immediately.

[digitalbuddha]

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?

[ZacSweers]

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.

[ZacSweers]

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 requestScope() method would do the swizzling with a default implementation.

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.

[ZacSweers]

Opened an issue on bazel to better understand how they avoid clean build churn - bazelbuild/bazel#4186

[ZacSweers]

Closing in favor of #198