3.x: Target Java version

[akarnokd]

Java 9 has recently been released with a couple of properties that can affect the next RxJava version's design:

Pros:

• Less memory use due to VarHandles: no more need for AtomicXXX class indirection
• New standard Reactive-Streams interoperation point java.util.concurrent.Flow
• Ability to prevent certain RxJava internal resource leaks via java.lang.ref.Cleaner
• Lambda usage in unit tests

Cons:

• VarHandles are reflection based, the ProGuard woes come back.
• May take several years Java 9 level API to become mainstream enough on the Android platform.
• Need for Gradle 4+ and the replacement of the now unsupported rxjava-nebula plugin. We successfully switched to Gradle and dropped that plugin.

[artem-zinnatullin]

Java 9 shipped JEP 238 "Multi-Release JAR Files" which allows you to have JDK-x specific classes/resources in a single jar.

For now it's just a "link drop". Hope someone will have time for deep investigation of applicability of this feature for RxJava 3.x.

My main concern is that it'll lead to huge code duplication and/or lots of wrappers for JDK-x specific types in RxJava repo.

[ZacSweers]

Need for Gradle 4+ and the replacement of the now unsupported rxjava-nebula plugin.

I think this is pretty manageable. If you're open to switching hosting to maven central starting with 3.x, this is quite easy to set up project-structure-wise.

I think the android bit is going to be difficult. You could however move to java 8 (if you avoid default/static methods in interfaces) and support the upcoming D8/desguar toolchain in the android sdk. That would be a pretty good win in itself.

[JakeWharton]

Is there a reason for an RxJava 3 to exist? The only interesting one I see above would be native Flow support but a multi-release jar would allow that to be supported on Java 9 only. What fundamental design flaws would this solve from 2?

[zyxist]

@artem-zinnatullin -> multi-release JAR-s could actually be used to ship some JDK9 features to RxJava 2. Their idea is simple. You build your project against e.g. JDK6 and package it normally, so that Java 6 would see no difference. Then, you can package variants of certain classes that target JDK9, into META-INF/versions. Java 9 knows that these variants "override" the original versions, and Java 6/7/8 works with older versions.

The main issue is that no build system currently supports them, and there is no agreed convention on the directory structure. I'm working on a Gradle plugin for Jigsaw, and I'm thinking about adding a support for multi-release JAR-s. If you are interested, we can make some experiments with them on RxJava (separate branch) to see, how they work in practice.

I think that the duplication can be limited to just four base interfaces from Flow. Java 6 could use the "base" versions, and for Java 9, these interfaces can simply extend those ones from Flow. This approach was used by Guava folks to provide interoperability between their functional interfaces, and java.util.functional and it worked there.

[akarnokd]

I suspected multi-release jars can't be used for adding API because javac compiles always against the normal classes. Their purpose is to runtime-replace implementations with the exact same API. See ktoso's excellent blog post.

[zyxist]

@akarnokd -> good post, thanks. So it looks that mr-jars don't solve the compatibility with Flow, at least for now.

[zyxist]

@akarnokd -> ktoso just told me that he might have made a mistake in his post, and that MR-JARs are supported by the compiler. This is a fresh finding (see the comment in the post that appeared 3 hours ago) and he's checking that right now :). So stay tuned!

[vietj]

@zyxist any update on this ?

[cogman]

I would suggest 8 as the target version for rxJava. Primarily because Java is going to a lts model for java and 8 is going to be the current lts (9 is slated for short term support). The other reason for targeting 8 minimum is to get features like invokedynamic into play.

http://www.oracle.com/technetwork/java/javase/eol-135779.html

[JakeWharton]

There's no point in talking about supported Java version until a case for an RxJava 3 is made. It's not unreasonable to think that Java 11 could be the minimum supported version at this point, seeing as it's only 8 months away and a likely candidate to be an LTS release.

…

On Fri, Sep 29, 2017 at 12:19 AM Artem Zinnatullin :slowpoke: < ***@***.***> wrote: Java 9 shipped JEP 238 "Multi-Release JAR Files" <http://openjdk.java.net/jeps/238> which allows you to have JDK-x specific classes/resources in a single jar. For now it's just a "link drop". Hope someone will have time for deep investigation of applicability of this feature for RxJava 3.x. My main concern is that it'll lead to huge code duplication and/or lots of wrappers for JDK-x specific types in RxJava repo. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5620 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEdZR8Y-U_cKwELEQbAIeV05punjyks5snG_rgaJpZM4Pj8Ik> .

[akarnokd]

I don't see much reason to target JDK 8; interoperating with the Stream and CompletableFuture is not much of a win and there is a library for that.

JDK 9+ offer performance and memory usage improvements along with the standard Flow API. For us, the Java API level matters more than it being a LTS or not.

I haven't seen any 10+ feature we really need. Local type inference is a convenience for new code, not for existing code using the full type definition already. I don't see much use for switch expressions either.

[klausmyrseth]

FYI Java 8 is end of life as of 31st december 2018, after that you need a commercial license from oracle to use it for anything semi serious. It would be fairly good to get jdk 10 support as soon as possible, as jdk 9-10 was ment as transition releases to ease the pain in moving to 11. If you're 10 compatible you work on 11.

As it is now I would get fired if I suggest another library that holds us back from transitioning to 11 when it comes. So I would think target java 10/11 would be a good version 3 candidate alone.

Only feature which is nice is the container support, but the important here is jdk8 is dying quickly and everyone is trying to actually transition to 10 and 11 when it comes now to be ready ;)

Would be awesome if the libraries one use would take the same step.

[akarnokd]

@klausmyrseth It is the API level, that is Java 6 currently, that matters. RxJava runs on Java 6-10 runtimes without problems and it is not dependent upon if a runtime is LTS or not.

Java 10 & 11 don't have any language features relevant for us. The first interesting upcoming feature is the value types where significant code adaptation will be required.

[klausmyrseth]

The major job that were taking now to get to jdk10 is to get the build and dependency management up to pair for jdk10/11, its quite a job for a larger project especially since we have to do some lifting on behalf of the underlying libraries as well.

Perhaps the external api is not breaking and validating a major release, but the build system needs some heavy lifting...

[akarnokd]

I'm not sure what you mean. Currently the build matrix looks promising, however, there are some issues with Jacoco and Java 11 class file format. Otherwise, if you are not building RxJava itself, it should still work in whatever project and language level beyond 6 you use.

[akarnokd]

I decided RxJava 3.x will remain a single Java 6 supporting library. Since Android moves away from Java towards Kotlin and Project Reactor & Spring will keep up with Java, there is no real need to bump up the minimum requirement for the time being.

[mattwelke]

See reactive-streams/reactive-streams-jvm#394 (comment) excellent blog post.

Any chance there's a working link to this blog post? I'm just now learning about reactive programming in Java, getting confused about why there are so many libraries, and this sounds like it'd be a good read. That link results in a Ghost error right now.