Releases · ReactiveX/RxJava

16 Dec 04:37

benjchristensen

v1.0.3

0f2e883

1.0.3

Pull 1928 Experimental: Add onBackpressureBuffer with capacity
Pull 1946 Experimental: AbstractOnSubscribe to help build Observables one onNext at a time.
Pull 1960 Beta: doOnRequest
Pull 1965 Fix the issue that Sample doesn't call 'unsubscribe'
Pull 1966 Fix NPE when the key is null in GroupBy
Pull 1964 Handle 0 or negative request in Buffer
Pull 1957 Fix 'request(0)' issue in Scan
Pull 1950 Add "Subscriptions.unsubscribed" to fix the 'isUnsubscribed' issue
Pull 1938 Any/All should not unsubscribe downstream.
Pull 1968 Upgrade to Gradle 2.2
Pull 1961 Remove Request Batching in Merge
Pull 1953 Fixed timer cast-to-int crash causing incorrect benchmark.
Pull 1952 Remove ActionSubscription
Pull 1951 Remove extraneous request(n) and onCompleted() calls when unsubscribed.
Pull 1947 Fixed first emission racing with pre and post subscription.
Pull 1937 Scheduler.Worker to be finally unsubscribed to avoid interference
Pull 1926 Move the codes out of the finally block
Pull 1922 Set removeOnCancelPolicy on the threadpool if supported

Artifacts: Maven Central

Assets 2

02 Dec 06:35

benjchristensen

v1.0.2

e2c6ced

1.0.2

This release adds @Beta and @Experimental annotations to mark APIs that are not yet stable.

An example of how this looks in the Javadocs is:

@Experimental
public final Observable<T> onBackpressureBlock()

The lifecycle and stability of these are documented in the README as follows:

@beta

APIs marked with the @Beta annotation at the class or method level are subject to change. They can be modified in any way, or even removed, at any time. If your code is a library itself (i.e. it is used on the CLASSPATH of users outside your own control), you should not use beta APIs, unless you repackage them (e.g. using ProGuard, shading, etc).

@experimental

APIs marked with the @Experimental annotation at the class or method level will almost certainly change. They can be modified in any way, or even removed, at any time. You should not use or rely on them in any production code. They are purely to allow broad testing and feedback.

Pull 1905 Beta & Experimental Annotations
Pull 1907 Experimental: onBackpressureBlock
Pull 1903 Fix TestScheduler Handling of Immediate vs Virtual Time
Pull 1898 Scheduled action no interrupt
Pull 1904 Fix the bug that Scan may request 0 when n is 1
Pull 1912 Fixed retry without backpressure & test function to support bp

Artifacts: Maven Central

Assets 2

29 Nov 05:27

benjchristensen

v1.0.1

37314b0

1.0.1

Pull 1893 Fixed incorrect error merging.
Pull 1901 Fixed redo & groupBy backpressure management

Artifacts: Maven Central

Assets 2

18 Nov 14:21

benjchristensen

v1.0.0

3dc4a31

1.0.0

After 2+ years of internal and open source development, 3600+ commits, 100+ releases, and with the help of 97 contributors RxJava has hit version 1.0.0.

Thank you @headinthebox @zsxwing @samuelgruetter @akarnokd @quidryan @DavidMGross @abersnaze @jmhofer @mairbek @mttkay @daveray @mattrjacobs @michaeldejong @MarioAriasC @johngmyers @pron @jbripley @davidmoten @gliptak @johnhmarks @jloisel @billyy @prabirshrestha @ragalie @abliss @dpsm @daschl @thegeez and the many other contributors and those who have reported bugs, tweeted, blogged or presented about RxJava.

The quality of this release could not have been achieved without all of your help. Thank you for your involvement and for building a community around this project.

JVM Language Adaptors & Subprojects

As of 1.0 the JVM language adapters and other subprojects no longer live under RxJava but have been separated out into their own projects with their own release cycles:

Versioning

Version 1.x is now a stable API and will be supported for several years.

Minor 1.x increments (such as 1.1, 1.2, etc) will occur when non-trivial new functionality is added or significant enhancements or bug fixes occur that may have behavioral changes that may affect some edge cases (such as dependence on behavior resulting from a bug). An example of an enhancement that would classify as this is adding reactive pull backpressure support to an operator that previously did not support it. This should be backwards compatible but does behave differently.

Patch 1.x.y increments (such as 1.0.0 -> 1.0.1, 1.3.1 -> 1.3.2, etc) will occur for bug fixes and trivial functionality (like adding a method overload).

Roadmap and Known Issues

1.0.x milestone with known issues
1.1 milestone with additional support for reactive pull backpressure
1.x is a catch all for other items that may be pursued in 1.2, 1.3 and later versions.

Change Log

all deprecated methods and types from v0.20 and earlier are deleted
now published to groupId io.reactivex instead of com.netflix.rxjava
artifactId is now rxjava instead of rxjava-core

io.reactivex:rxjava:1.0.0

Following are specific changes from 0.20 to 1.0 to be aware of:

groupBy/groupByUntil

The groupByUntil operator was removed by collapsing its behavior into groupBy. Previously on groupBy when a child GroupedObservable was unsubscribed it would internally retain the state and ignore all future onNext for that key.

This matched behavior in Rx.Net but was found to be non-obvious and almost everyone using groupBy on long-lived streams actually wanted the behavior of groupByUntil where an unsubscribed GroupedObservable would clean up the resources and then if onNext for that key arrived again a new GroupedObservable would be emitted.

Adding backpressure (reactive pull) to groupByUntil was found to not work easily with its signatures so before 1.0 Final it was decided to collapse groupBy and groupByUntil. Further details on this can be found in Pull Request 1727.

Here is an example of how groupBy now behaves when a child GroupedObservable is unsubscribed (using take here):

// odd/even into lists of 10
Observable.range(1, 100)
        .groupBy(n -> n % 2 == 0)
        .flatMap(g -> {
            return g.take(10).toList();
        }).forEach(System.out::println);

[1, 3, 5, 7, 9, 11, 13, 15, 17, 19]
[2, 4, 6, 8, 10, 12, 14, 16, 18, 20]
[21, 23, 25, 27, 29, 31, 33, 35, 37, 39]
[22, 24, 26, 28, 30, 32, 34, 36, 38, 40]
[41, 43, 45, 47, 49, 51, 53, 55, 57, 59]
[42, 44, 46, 48, 50, 52, 54, 56, 58, 60]
[61, 63, 65, 67, 69, 71, 73, 75, 77, 79]
[62, 64, 66, 68, 70, 72, 74, 76, 78, 80]
[81, 83, 85, 87, 89, 91, 93, 95, 97, 99]
[82, 84, 86, 88, 90, 92, 94, 96, 98, 100]

Previously this would have only emitted 2 groups and ignored all subsequent values:

[1, 3, 5, 7, 9, 11, 13, 15, 17, 19]
[2, 4, 6, 8, 10, 12, 14, 16, 18, 20]

On a finite stream, similar behavior of the previous groupBy implementation that would filter can be achieved like this:

//odd/even into lists of 10
Observable.range(1, 100)
        .groupBy(n -> n % 2 == 0)
        .flatMap(g -> {
            return g.filter(i -> i <= 20).toList();
        }).forEach(System.out::println);

[1, 3, 5, 7, 9, 11, 13, 15, 17, 19]
[2, 4, 6, 8, 10, 12, 14, 16, 18, 20]

That however does allow the stream to complete (which may not be wanted).

To unsubscribe here are some choices that get the same output but efficiently unsubscribe up so the source only emits 40 values:

Observable.timer(0, 1, TimeUnit.MILLISECONDS)
        .groupBy(n -> n % 2 == 0)
        .flatMap(g -> {
            return g.take(10).toList();
        }).take(2).toBlocking().forEach(System.out::println);

Observable.timer(0, 1, TimeUnit.MILLISECONDS)
        .take(20)
        .groupBy(n -> n % 2 == 0)
        .flatMap(g -> {
            return g.toList();
        }).toBlocking().forEach(System.out::println);

These show that now groupBy composes like any other operator without the nuanced and hidden behavior of ignoring values after a child GroupedObservable is unsubscribed.

Uses of groupByUntil can now all be done by just using operators like take, takeWhile and takeUntil on the GroupedObservable directly, such as this:

Observable.from(Arrays.asList("a", "b", "c", "a", "b", "c", "a", "b", "c", "a", "b", "c", "a", "b", "c", "a", "b", "c"))
        .groupBy(n -> n)
        .flatMap(g -> {
            return g.take(3).reduce((s, s2) -> s + s2);
        }).forEach(System.out::println);

aaa
bbb
ccc
aaa
bbb
ccc

retryWhen/repeatWhen

The retryWhen and repeatWhen method signatures both emitted a Observable<Notification> type which could be queried to represent either onError in the retryWhen case or onCompleted in the repeatWhen case. This was found to be confusing and unnecessary. The signatures were changed to emit Observable<Throwable> for retryWhen and Observable<Void> for repeatWhen to better signal the type of notification they are emitting without the need to then query the Notification.

The following contrived examples shows how the Observable<Throwable> is used to get the error that occurred when deciding to retry:

    AtomicInteger count = new AtomicInteger();
    Observable.create((Subscriber<? super String> s) -> {
        if (count.getAndIncrement() == 0) {
            s.onError(new RuntimeException("always fails"));
        } else {
            s.onError(new IllegalArgumentException("user error"));
        }
    }).retryWhen(attempts -> {
        return attempts.flatMap(throwable -> {
            if (throwable instanceof IllegalArgumentException) {
                System.out.println("don't retry on IllegalArgumentException... allow failure");
                return Observable.error(throwable);
            } else {
                System.out.println(throwable + " => retry after 1 second");
                return Observable.timer(1, TimeUnit.SECONDS);
            }
        });
    })
    .toBlocking().forEach(System.out::println);

collect

The collect operator was changed to require a factory method for the initial value. This allows the Observable to be executed multiple times and get a new value (typically a mutable data structure) each time. Prior to this the Observable could only be subscribed to once since it would retain the original mutable data structure and keep mutating it.

Observable.range(0, 10).collect(() -> new ArrayList<Integer>(), (list, i) -> {
    list.add(i);
}).forEach(System.out::println);

Removed Scheduler.parallelism

The Scheduler.parallelism method was no longer being used by anything so was removed.

Removed Observable.parallel

The parallel operator was a failed experiment and almost all uses of it were wrong and led to confusion and often bad performance. Due to this it was removed.

Here is example code to show approaches to adding concurrency:

import rx.Observable;
import rx.Subscriber;
import rx.schedulers.Schedulers;

public class ParallelExecution {

    public static void main(String[] args) {
        System.out.println("------------ mergingAsync");
        mergingAsync();
        System.out.println("------------ mergingSync");
        mergingSync();
        System.out.println("------------ mergingSyncMadeAsync");
        mergingSyncMadeAsync();
        System.o...

Assets 2

17 Nov 18:44

benjchristensen

v1.0.0-rc.12

7181145

1.0.0-RC12 Pre-release

Pre-release

Pull 1886 Buffer with time and merge fix

Artifacts: Maven Central

Assets 2

15 Nov 20:51

benjchristensen

v1.0.0-rc.11

d6cbf59

1.0.0-RC11 Pre-release

Pre-release

NOTE: A problem with Maven Central syncing prevented this from being published but it is available on JCenter.

This release had to revert changes to scan/reduce in the previous rc.10 release due to issues found with lambdas and overload ambiguity. Mutable reduce at this time is achievable via a modified (breaking change) collect operator like this:

Observable.range(0, 10).collect(() -> new ArrayList<Integer>(), (list, i) -> {
    list.add(i);
}).forEach(System.out::println);

The collect operator now requires the initial value as a Func0<T>.

Pull 1882 Remove Unused Scheduler.parallelism
Pull 1884 Fix Scan/Reduce/Collect Factory Ambiguity
Pull 1866 Fix memory leak in bounded ReplaySubject due to retaining the node index

Artifacts: Maven Central

Assets 2