Upgrade Gradle & Build-Time dependencies to allow building with JDK 11

[Erlkoenig90]

I would like to propose updating some build-time dependencies to their respective recent versions:

• Gradle 5.5.1
• AnimalSniffer plugin to 1.5.0, tool to 1.18
• Jacoco to 0.8.4

This would allow us to run builds on JDK 11. Unlike #6317, the target/source compatibility versions could be kept, keeping backwards compatibility of the built library. However, we couldn't build on JDK 7 anymore, since Gradle 5.5.1 requires at least JDK 8.

[akarnokd]

Upgrading Gradle has the risk of breaking the release process. The current setup works well.

There are separate repositories of mine,

• https://github.com/akarnokd/RxJava3_BuildMatrix
• https://github.com/akarnokd/RxJava2_9

which specify a build matrix for further testing.

[Erlkoenig90]

Upgrading Gradle has the risk of breaking the release process.

How can we test this properly?

The current setup works well.

Unless you try gradle composite builds, e.g.:

~/Projects/RxTest $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64/ ./gradlew build --include-build ../RxJava

FAILURE: Build failed with an exception.

* Where:
Build file '~/Projects/RxJava/build.gradle' line: 39

* What went wrong:
A problem occurred evaluating project ':rxjava'.
> Missing implementation of resolved method abstract configureConfiguration(Lorg/gradle/api/artifacts/Configuration;)V of abstract class org.gradle.api.plugins.quality.internal.AbstractCodeQualityPlugin.

This error is caused by AnimalSniffer; here, gradle 5.5.1 is forced by the application project (RxTest). If JDK 11 is required by the application, we can't build it that way. Of course, one can always build RxJava separately and import the JAR file, but that's less comfortable. If RxJava could be built with JDK 11, both projects can be comfortably compiled by IDEs (e.g. IDEA) as a composite build just by importing them. Or is there another way?

[akarnokd]

How can we test this properly?

You can't. I'd have to prepare a new release over and over. Also the OSGi parts (that jar manifest part) have to be migrated as well.

Why do you want to build it with Java 11? A proper release requires CI, which works right now so no reason to upgrade there. Do you use custom compiled builds of RxJava?

[Erlkoenig90]

You can't. I'd have to prepare a new release over and over. Also the OSGi parts (that jar manifest part) have to be migrated as well.

Okay, sorry, wasn't aware of that. My modifications looked harmless enough...

Why do you want to build it with Java 11?

Mostly to allow composite builds, and in order to not have to specify JDK 8 every time :)

Do you use custom compiled builds of RxJava?

Yes, I'm trying to improve the error handling - if/when I get it to work, is there interest in a PR?

[akarnokd]

improve the error handling [...] is there interest in a PR?

What kind of improvements? Error handling is delicate and what may seem working for you locally could cause problems in general.

[Erlkoenig90]

Error handling is delicate

I noticed :) As asked on SO, there appears to be no consistent way of freeing resources (e.g. files) associated with items. For example, ConcatMapSingleMainObserver buffers items in its members item and queue; if the chain is cancelled due to an error, there is no way for the application to access the items and clean the resources. Their memory is eventually freed by the GC, of course. So, I am thinking about some user-defined "cleaner" object that can be attached to observables and operators that would invoke it to clean up items that remain in the buffer. Basically an asynchronous try-with-resources.

[akarnokd]

That level of resource awareness is not part of RxJava and requires a completely different architecture. I've experimented with it separately and it was extremely tedious.

[Erlkoenig90]

That level of resource awareness is not part of RxJava

Hm, what is it part of? How can the example on SO be made to work, short of avoiding concurrency altogether?

[akarnokd]

You have to bring the computation to the resource so its lifecycle is serialized with operations to be performed on it. It can get quite complicated.

[Erlkoenig90]

Okay... I might try to put something together just because. In the meantime, I may have found another bug...

[akarnokd]

Closing via #6632