RxJava 2.0 Backward Compatibility...Or Not

[asarkar]

According to What's different in 2.0, in order to remain binary compatible with Java 6, the team decided to implement their own functional interfaces. I played around with 2.0 a little bit today and immediately found this very confusing, always having to choose among classes with same name and methods, not to mention the proverbial reinvention of wheel. If Google Guava is on classpath, it makes matters worse because it also has Function and Supplier classes. Consider the introduction of generic on Java 5. In order to remain binary compatible with older JDK, they thought erasure was a good idea. It wasn't. For the next decade, thousands of lines of code were written to hack around that issue. I'm pretty sure that decision will go down as a failed design choice in Java, not unlike checked exceptions. I don't know when 2.0 final release is planned for but assuming it's end of 2016 or beginning of 2017, it's not unreasonable to depend on Java 8 released almost 3 years ago (March 18, 2014). Please don't give in to the corporate thought process where the only code changes funded for are those that make money. 3 years is a long enough time for someone to upgrade to Java 8. If they still don't, 1.x is not going anywhere.

[JakeWharton]

Android

[asarkar]

@JakeWharton Didn't follow. Are you saying that sticking with Java 6 is to support Android?

[JakeWharton]

Yep!

On Sat, Sep 3, 2016 at 8:43 PM Abhijit Sarkar notifications@github.com wrote:

@JakeWharton https://github.com/JakeWharton Didn't follow. Are you saying that sticking with Java 6 is to support Android?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/ReactiveX/RxJava/issues/4471#issuecomment-244577752, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEEEffxS03-rlAlZik0uLEEClcY6Md5ks5qmhQigaJpZM4J0bDU .

[asarkar]

How much of the userbase is Android? If they're not the majority, why should most people suffer due to a few?

[JakeWharton]

It's impossible to know, but I'd wager they're the majority but a non-trivial margin.

Besides, your arguments are weak at best. Generics and checked exceptions are irrelevant to anything (and you're wrong anyway). Lambda / method ref inference means calling code never sees the interface names and the type system means that when you actually do need to implement them you're forced to the right one.

I personally much prefer the Action* and Func* names from 1.x, but none of the things you said resonate with me as motivation for a change.

Please don't give in to the corporate thought process where the only code changes funded for are those that make money

This reads like you don't know much about how this project is developed or managed.

[asarkar]

Generics and checked exceptions are irrelevant to anything (and you're wrong anyway)

The reason behind type erasure is to support older JVMs that didn't understand generics. That's the definition of backward compatibility which the JDK designers stuck to at that time. I'm not wrong in that. Not sure what your rest of the statement means; perhaps you misunderstood my reference to generics.

Please don't give in to the corporate thought process where the only code changes funded for are those that make money

This reads like you don't know much about how this project is developed or managed.

That was for the users of RxJava, not for the project. What I meant, and is true, is that companies rarely shell out time and cash to support framework upgrades if it doesn't have business prospects.

Anyway, I think now we're splitting hairs. In reality, Android doesn't have to upgrade to 2.0 until they get to Java 8 but if you still want introduce duplicate code for their sake, that's up to you.

[JakeWharton]

I meant you're wrong about erasure being a bad thing.

On Sun, Sep 4, 2016 at 12:23 AM Abhijit Sarkar notifications@github.com wrote:

Generics and checked exceptions are irrelevant to anything (and you're wrong anyway)

The reason behind type erasure is to support older JVMs that didn't understand generics. That's the definition of backward compatibility which the JDK designers stuck to at that time. I'm not wrong in that. Not sure what your rest of the statement means; perhaps you misunderstood my reference to generics.

Please don't give in to the corporate thought process where the only code changes funded for >> are those that make money

This reads like you don't know much about how this project is developed or managed.

That was for the users of RxJava, not for the project. What I meant, and is true, is that companies rarely shell out time and cash to support framework upgrades if it doesn't have business prospects.

Anyway, I think now we're splitting hairs. In reality, Android doesn't have to upgrade to 2.0 until they get to Java 8 but if you still want introduce duplicate code for their sake, that's up to you.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/ReactiveX/RxJava/issues/4471#issuecomment-244583598, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEEEYaOuaSb0jKrtoepMoMV0WMlAXpuks5qmkepgaJpZM4J0bDU .

[LalitMaganti]

I would go far further than Jake and say that the vast majority of RxJava users are probably utilising Android. With SAM conversion in any case, why do you even care about the exact interfaces being used in Java 8? Just use lambdas and be done with it.

[akarnokd]

One year ago, RxJava 2.0 development started on Java 8 basis in the hopes that when it's done (within 2 weeks :) ) the majority of devices will be supporting Java 8 API on Android. Unfortunately, there are may devices out there still on Android 2.3 with practically Java 6 level of features.

Therefore, all Java 8 API use was stripped but we were facing the problem of the functional interface naming. Earlier this year, it has been decided that 1.x and 2.x should be able to live together, thus the naming in 2.x is now clashing 1.x <-> 2.x <-> Java 8. Factoring out the functional interfaces into a shared library may technically work, but that would break the binary compatibility of 1.x (due to throwing methods introduced in 2.x).

As the others mentioned, if you are using Java 8 or Retrolambda, you're unlikely to meet the actual interfaces. If you really have to type them out for some reason, most IDEs now seem to learn what types and packages you use and the content assist suggestions will list io.reactivex types high on the list. Otherwise, you can filter out any type you don't want to see in that list.

Please don't give in to the corporate thought process where the only code changes funded for are those that make money

This reads like you don't know much about how this project is developed or managed.

That was for the users of RxJava, not for the project. What I meant, and is true, is that companies rarely shell out time and cash to support framework upgrades if it doesn't have business prospects.

I'm not sure what you mean by this but I'm certain companies using RxJava 1.x do spend time to upgrade minor or patch versions of the library and it's part of their development/enhancement process. I don't think CEOs will disallow upgrading from 1.1.9 to 1.1.10 because it doesn't bring 2x speedup of their flagship app.

Although we are still under the Netflix banner, RxJava is a 100% community run project for some months now.

In reality, Android doesn't have to upgrade to 2.0 until they get to Java 8 but if you still want introduce duplicate code for their sake, that's up to you.

There is no reason to wait for that since RxJava 2 is Java 6 compatible and fully functioning filled with internal improvements such as lower memory and CPU overhead that I'm sure Android developers appreciate.

[artem-zinnatullin]

Just to clarify:

Unfortunately, there are may devices out there still on Android 2.3 with practically Java 6 level of features.

Most of Android devices nowadays run on Android 4.1 and above (see stats), Android 2.3 is only about 1.7%. But, yes, most of them still use Java 6 APIs (and partially 7). Hopefully in two years Android developers will be able to use Java 8 libraries without problems.

[asarkar]

With SAM conversion in any case, why do you even care about the exact interfaces being used in Java 8?

Because always using a lambda is an oversimplified scenario. More often than not, the code could use an anonymous implementation for the sake of reuse or a nested static class if constructor args are necessary.

Here's an example from my GitHub for use with retryWhen. We use a very similar one at work but based on 1.x.

public class RetryWithDelay implements
        Function<Flowable<? extends Throwable>, Publisher<Object>> {

    private final int maxRetries;
    private final long retryDelaySeconds;
    private final RetryDelayStrategy retryDelayStrategy;

    private int retryCount;
    // more code
}

Usage of the above RetryWithDelay:

Single.fromCallable(() -> { // stuff
 }).retryWhen(retryWithDelay)
    .subscribeOn(scheduler)
    .subscribe(// stuff);

That said, I got the impression that you guys already made up your mind on this, which is why I closed this thread. The reason I originally started this discussion was because the blog claimed it was "up for discussion".

[smaldini]

If you need java 8, take a look at Reactor 3, the same foundation than rxjava 2 but for Java 8, exclusively implementing RS in 2 types Flux and Mono, bridging natively to RxJava 1 & 2, and being the Spring Framework embedded library (supported for the years to come). In fact it appears RxJava2 and Reactor are continuously synchronizing features between themselves thanks to the Research Effort RSC and the open relationship @akarnokd and myself are in 👍 💃 .