Java 9 Flow使用lambdas定义订户

Question

我开始玩Java 9 Flow API，我发现并且不喜欢的第一件事，当我们将订阅者实现传递给发布者时，似乎我们不能使用lambdas，因为我们可以使用RxJava

所以我必须定义并实现我自己的Subscriber类

public class CustomSubscriber<T> implements Flow.Subscriber<T> {

        protected Flow.Subscription subscription;

        @Override
        public void onSubscribe(Flow.Subscription subscription) {
            this.subscription = subscription;
            System.out.println("Subscription done:");
            subscription.request(1);
        }

        @Override
        public void onNext(T item) {
            System.out.println("Got : " + item);
            subscription.request(1);
        }

        @Override
        public void onError(Throwable t) {
            t.printStackTrace();
        }

        @Override
        public void onComplete() {
            System.out.println("Done");
        }
    }

然后将其传递给我的发布者

   SubmissionPublisher<String> publisher = new SubmissionPublisher<>();
    publisher.subscribe(new CustomSubscriber<>());

这真的很冗长，据我所知，这是因为我们需要在onSubscribe回调中设置订阅

protected Flow.Subscription subscription;     

稍后在onNext中使用以继续排放subscription.request(1);

我仍然不明白为什么需要这种机制，但它避免像我们在RxJava中那样使用Lambdas作为这个例子

SubmissionPublisher<String> publisher = new SubmissionPublisher<>();
publisher.subscribe(item -> System.out.println("do something in the onNext"),
        e -> System.out.println("do something in the onError"),
        () -> System.out.println("Do something in the onComplete"));

我想这是不可能的，我在这里没有遗漏任何东西吗？

Answer 1

  

我仍然不明白为什么需要这种机制

订阅可实现从订阅者到发布者的通信。 request方法允许订户应用backpressure，通知上游组件它已经过载并且“需要中断”。为此，订阅者需要保留订阅的实例，并且需要偶尔致电request以获取更多项目。

无压力Subscriber

如果您有一个用例，在那里您不需要应用背压并且希望从降低的复杂性中受益，您可以实现LaidBackSubscriber，其中：

• 通过存储订阅并立即调用onSubscribe来实现request
• 通过执行构造期间给出的lambda然后调用onNext
来实现subscription.request(1)
• 通过执行施工期间给出的lambda来实现onError和onComplete

那应该能得到你想要的东西。

一般建议

Java 9 Flow API was created作为现有异步库的集成点，而不是以临时方式实现反应组件的邀请。试验很好，但是如果你真的想创建一个反应系统，那么现有的库可能非常适合。

Answer 2

Java 9 Flow API是一个由4个接口和1个桥接类组成的准系统，从非响应世界到被动世界。没有操作员，没有方便的lambda版本，没有别的。

从理论上讲，它的引入是为了让JDK本身能够根据反应原理构建内部组件，但没有令人放心的迹象。

因此，用户负责在此API上构建组件，这是困难，乏味且容易出错的。您最好等待主流库发布兼容版本，或者只是坚持使用更多可用的Reactive-Streams.Org库，例如RxJava 2和Reactor 3.

如果您仍然有兴趣手动构建Flow API，可以查看我的研究/原型库Reactive4JavaFlow，它具有所需的lambda重载{{3} }。