# Subscriber Published articles for Subscriber. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The Palindrome Announces a Graph Theory for Visual Learners Video Course DevFeed: [The Palindrome Announces a Graph Theory for Visual Learners Video Course]() Original publisher: [Read original article]() Author: Tivadar Danka Published: 2026-09-12T08:47:28Z Content type: opinion Language: en Sources: [The Palindrome]() Topics: [Graphs](), [math]() Tags: [graph](), [graph-theory](), [subscriber](), [video]() ### AI overview The Palindrome announces a planned comprehensive graph theory video course called "Graph Theory for Visual Learners" and launches a support campaign for paid subscribers and founding members. The project will use custom animations and include an upcoming video release. ### Source excerpt I'm creating The Palindrome's most ambitious video yet. Become a paid subscriber and be part of it. ## 10+ best practices to improve your email deliverability DevFeed: [10+ best practices to improve your email deliverability]() Original publisher: [Read original article]() Author: Jesse Sumrak Published: 2026-09-09T00:00:00Z Content type: tutorial Language: en Sources: [Twilio Blog]() Topics: [email](), [SendGrid](), [API]() Tags: [best-practices](), [deliverability](), [domain](), [email](), [industry-insights](), [marketing](), [sendgrid](), [spam](), [spoofing](), [subscriber]() ### AI overview This tutorial explains email deliverability and presents more than ten practices for improving inbox placement, including domain authentication, double opt-in, non-spammy subject lines, list cleaning, and avoiding spam traps. It also distinguishes delivery from deliverability and discusses sender reputation and subscriber engagement. ### Source excerpt Email deliverability determines whether your messages reach inboxes or spam folders. Follow these 10+ best practices to improve your deliverability rates. ## History of SpaceX: The Category-Dominating Commercial Spinoff and the Internalization of Anchor Demand DevFeed: [History of SpaceX: The Category-Dominating Commercial Spinoff and the Internalization of Anchor Demand]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-04T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [communications](), [Deployment](), [service]() Tags: [aerospace](), [beta](), [business](), [capacity](), [customer](), [deployment](), [history](), [international](), [launches](), [operational](), [partnership](), [regulatory](), [revenue](), [service](), [spacex](), [subscriber]() ### AI overview This article examines SpaceX's commercial spinoff as the internalization of an anchor customer. It explains how the spinoff consumes the parent's launch output at marginal cost, traces its deployment, service rollout, integration, subscriber and revenue development, direct-to-cell expansion, capital requirements, and regulation, and compares the configuration with other satellite-constellation businesses. ### Source excerpt This article is the eleventh in the History of SpaceX series and the third and last treating the capital-formation legs that the series opener introduced. The category-dominating commercial spinoff concerns the business the venture built on top of its own capability, and the article's organizing claim is that the spinoff is not a diversification into an adjacent market but the internalization of an anchor customer. Where the Anchor Demand article A283 treats a government customer buying launches, this article treats the venture becoming the customer it had previously needed someone else to be. The decisive economic property is not that the spinoff grew large. It is that the spinoff consumes the parent's output at marginal cost while every competitor attempting the same business must pay a market price the parent sets. The article walks the January 2015 announcement and the capacity argument that motivated it, the deployment sequence from the first operational batch of May 2019 through the service beta of 2020 and the commercial rollout of 2021, the vertical integration and the internal transfer price that the whole arrangement turns upon, the coupling between constellation deployment and launch cadence, the subscriber and revenue trajectory across the 2020 through drafting-date period, the direct-to-cell extension beginning with the carrier partnership announced in 2022, the capital intensity and the replenishment obligation that a short-lifetime constellation imposes, and the regulatory position across the Federal Communications Commission, the International Telecommunication Union, and the national regulators whose authorizations the service requires. The article contrasts the configuration against the Iridium and Globalstar precedents, in which comparable constellations were built without a captive launch capability, and against the OneWeb and Kuiper cases, in which competitors attempted the business while buying launch at market. The article closes with an expli ## An Interactive Study of Publish/Subscribe Messaging for Event-Driven Backend Systems DevFeed: [An Interactive Study of Publish/Subscribe Messaging for Event-Driven Backend Systems]() Original publisher: [Read original article]() Author: Ivan Cernja Published: 2026-04-24T00:00:00Z Content type: tutorial Language: en Sources: [Encore Updates]() Topics: [Publish-subscribe pattern](), [Messaging](), [Back end](), [distributed-systems](), [event driven]() Tags: [decoupling](), [developers](), [distributed-systems](), [event-driven](), [events](), [flow](), [messaging](), [patterns](), [publisher](), [subscriber]() ### AI overview An interactive tutorial explains publish/subscribe messaging by contrasting it with direct service calls. It shows how topics decouple publishers from subscribers, support fan-out, and let subscribers process messages independently, including when downstream services are unavailable. ### Source excerpt An interactive study of publish/subscribe messaging ## The city of systems: Temporal, Kafka, and Nexus DevFeed: [The city of systems: Temporal, Kafka, and Nexus]() Original publisher: [Read original article]() Author: Tao Guo Published: 2025-12-10T00:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [Kafka](), [Event-Streaming](), [distributed-systems]() Tags: [distributed-systems](), [event-streaming](), [kafka](), [partitions](), [publisher](), [queues](), [streaming](), [subscriber](), [temporal-voices]() ### AI overview The article presents Temporal, Kafka, and Nexus as complementary building blocks for distributed systems. It explains Kafka's publisher-subscriber model, consumer groups, and partitions, while noting that its high-volume event broadcasting can be vulnerable to lost signals and stalled processing. ### Source excerpt Temporal, Kafka, and Nexus create the blueprint for great distributed systems, balancing high-speed event streaming with guaranteed certainty. ## Matter: Device-to-Device Automations DevFeed: [Matter: Device-to-Device Automations]() Original publisher: [Read original article]() Author: John Lee Published: 2021-12-07T00:00:00Z Content type: article Language: en Sources: [Blog on Developer Portal]() Topics: [Matter](), [Network](), [client](), [Server]() Tags: [app](), [article](), [blog](), [communication](), [devices](), [esp32](), [iot](), [local](), [matter](), [network](), [phone-app](), [subscriber]() ### AI overview This article explains how Matter devices can interact directly over a local network to create automations. It covers device binding, synchronous control, and asynchronous notification through publisher-subscriber relationships. ### Source excerpt [This is article #3 in the Espressif Matter Series of articles. You may read the second part here.] In the previous article we looked at the data model of Matter. Today, let us talk about how Matter devices within a network can interact with each other leading to useful automations. For instance, you may want a light switch at your home to control one or more light bulbs. Or even a thermostat to turn on or off based on reports from the occupancy sensor. ## Java 9 Flow API: Multicasting via a Processor DevFeed: [Java 9 Flow API: Multicasting via a Processor]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-12-14T13:20:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Java](), [Java 9](), [reactive](), [Streams](), [implementation](), [API]() Tags: [backpressure](), [cancellation](), [concurrency](), [flow](), [flow-api](), [java](), [java-9](), [jdk](), [multicast](), [processor](), [reactive](), [reactive-streams](), [streams](), [subscriber](), [subscription](), [tck]() ### AI overview This tutorial explains how Java 9 Flow API processors can multicast elements from a single upstream source to multiple consumers. It focuses on coordinating subscriber demand, backpressure, dynamic subscription, and cancellation, and introduces MulticastProcessor as the intermediate solution. ### Source excerpt Introduction There are situations when the same elements of a source should be dispatched to multiple consumers. Certainly, if the source supports multiple subscribers and is deterministic (such as our previous async range), one can just instantiate the flow multiple times. However, if the source doesn't support multiple subscribers or each subscription ends up being unique and/or non-deterministic, that simple approach doesn't work anymore. We need a way to have a single realization of the (upstream) source yet allow multiple consumers. Since we are dealing with Flow.Publishers that require backpressure management, such intermediate solution has to coordinate requests from its Flow.Subscribers in addition to handling the dynamic subscription and unsubscription (cancellation) of said Flow.Subscribers while the flow is active. Enter, MulticastProcessor. Flow.Processor recap What is a Processor? By definition, it is a combination of a Flow.Publisher and a Flow.Subscriber, i.e., it can act as a source and can be subscribed to via subscribe() as well as the processor itself can be used with somebody else's Flow.Publisher.subscribe(). It has a mixed history as the idea comes from the original Observer pattern (i.e., java.util.Observable) and Rx.NET's Subject that allows dispatching signals to multiple Observers in an imperative (and synchronous) fashion. The Flow.Processor in Java 9 defines two type arguments, one for its input side (Flow.Subscriber) and one for its output side (Flow.Publisher). The idea behind it was that a Flow.Processor can act as a transformation step between an upstream and a downstream. However, such transformation often mandates the Flow.Processor implementation only accepts a single Flow.Subscriber during its entire lifetime. Since the implementation has to follow the Reactive Streams specification nonetheless, this adds a lot of overhead to the flow. As demonstrated in previous posts, when a flow is realized, there are only one subscriber per st ## Java 9 Flow API: taking and skipping DevFeed: [Java 9 Flow API: taking and skipping]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-30T20:44:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Java 9](), [API](), [reactive]() Tags: [api](), [flow](), [flow-api](), [implementation](), [java-9](), [jdk](), [publisher](), [reactive](), [reactive-streams](), [skip](), [skipwhile](), [streams](), [subscriber](), [subscription](), [take](), [takeuntil](), [takewhile]() ### AI overview A tutorial on implementing take and skip-style operators with Java 9's Flow API. It explains how to limit a flow, cancel the upstream subscription when the limit is reached, complete the downstream subscriber, handle terminal events, and account for backpressure behavior. ### Source excerpt Introduction Limiting or skipping over parts of a flow is a very common task: either we are only interested in the first N items or we don't care about the first N items. Sometimes, N is unknown but we can decide, based on the current item, when to stop relaying items or, in contrast, when to start relaying items. Take(N) In concept, limiting a flow to a certain size should be straightforward: count the number of items received via onNext and when the limit is reached, issue a cancel() towards the upstream and onComplete() towards the downstream. public static Flow.Publisher take(Flow.Publisher source, long n) { return new TakePublisher<>(source, n); } The operator's implementation requires little state: static final class TakeSubscriber implements Flow.Subscriber { final Flow.Subscriber downstream; Flow.Subscription upstream; long remaining; TakeSubscriber( Flow.Subscriber downstream, long n) { this.downstream = downstream; this.remaining = n; } @Override public void onSubscribe(Flow.Subscription s) { // TODO implement } @Override public void onNext(T item) { // TODO implement } @Override public void onError(Throwable throwable) { // TODO implement } @Override public void onComplete() { // TODO implement } } In its simplest form, there is no need for intercepting the request() and cancel() calls from the downstream: these can be passthrought, however, since the operator has to stop the sequence upon reaching the limit (remaining == 0), the upstream's Flow.Subscriber has to be stored. @Override public void onSubscribe(Flow.Subscription s) { this.upstream = s; downstream.onSubscribe(s); } In onSubscribe, we only have to store the Flow.Subscription and forward it to the downstream. @Override public void onNext(T item) { long r = remaining; if (r > 0L) { remaining = --r; downstream.onNext(item); if (r == 0) { upstream.cancel(); downstream.onComplete(); } } } While remaining is positive, we decrement it and save it into its field foll ## Java 9 Flow API: arbitration and concatenation DevFeed: [Java 9 Flow API: arbitration and concatenation]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-27T12:55:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Java 9](), [Java](), [API]() Tags: [api](), [arbiter](), [arbitration](), [concat](), [concatenation](), [concurrent](), [event](), [flow](), [flow-api](), [java](), [java-9](), [jdk](), [onerrorresumenext](), [publisher](), [repeat](), [request](), [retry](), [submissionpublisher](), [subscriber](), [subscription](), [subscriptionarbiter]() ### AI overview This tutorial explains how to implement subscription arbitration for Java 9's Flow API when concatenating multiple publishers. It addresses stack growth, remaining-demand accounting, concurrent requests and cancellation, subscription switching, and produced-item tracking. ### Source excerpt Introduction A very common task is to combine multiple sources, or more generally, start consuming a source once the previous source has terminated. The naive approach would be to simply call otherSource.subscribe(nextSubscriber) from onError or onComplete. Unfortunately, this doesn't work for two reasons: 1) it may end up with deep stacks due to a "tail" subscription from onError/onComplete and 2) we should request the remaining, unfulfilled amount from the new source that hasn't be provided by the previous source to not overflow the downstream. The first issue can be solved by applying a heavyweight observeOn in general and implementing a basic trampolining loop only for certain concrete cases such as flow concatenation to be described in this post. The second issue requires a more involved source: not only do we have to switch between Flow.Subscriptions from different sources, we have to make sure concurrent request() invocations are not lost and are routed to the proper Flow.Subscription along with any concurrent cancel() calls. Perhaps the difficulty is lessened by the fact that switching sources happens on a terminal event boundary only, thus we don't have to worry about the old source calling onNext while the logic switches to the new source and complicating the accounting of requested/emitted item counts. Enter SubscriptionArbiter. Subscription arbitration We have to deal with 4 types of potentially concurrent signals when arbitrating Flow.Subscriptions: A request(long) call from downstream that has to be routed to the current Flow.Subscription A cancel() call from downstream that has to be routed to the current Flow.Subscription and cancel any future Flow.Subscription. A setSubscription(Flow.Subscription) that is called by the current Flow.Subscriber after subscribing to any Flow.Publisher which is not guaranteed to happen on the same thread subscribe() is called (i.e., as with the standard SubmissionPublisher or our range() operator). A setProduced(long n) ## Java 9 Flow API: timing out events DevFeed: [Java 9 Flow API: timing out events]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-25T11:46:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [reactive](), [Java 9](), [Concurrency](), [Programming](), [Streams]() Tags: [await](), [concurrency](), [flow](), [flow-api](), [java-9](), [jdk](), [programming](), [reactive](), [reactive-programming](), [streams](), [subscriber](), [subscription](), [timeout]() ### AI overview This tutorial explains how to design a timeout operator for Java 9 Flow API publishers. It models each event as a race between item arrival and a timer, signals a TimeoutException when the timer wins, and addresses serialized downstream signals when timeout and upstream events occur concurrently. ### Source excerpt Introduction One of the main properties of reactive programming is that the events may arrive over time instead of immediately available to a consumer. In traditional Future-based programming, one could wait for the result in a blocking manner via Future.get(long, TimeUnit). Other data sources, such as network InputStream have either their own built-in timeout facility or one has to use external means to close the stream after certain period of time to unblock the reader to it. Java 8 Streams have also no direct timeout support. In the reactive mindset, one can consider timing out events (items) as requesting an element and racing its arrival against the clock. If the item arrives in time, we should ignore the clock. If the clock fires first, we should stop the sender of the items and somehow notify the consumer of the situation. Perhaps the simplest way is to signal onError with a TimeoutException. Since there could be multiple items from a flow, we have to do this racing for each potential items over and over until the flow terminates. The timeout operator Since there is "time" in timeout, we'll need a source of time that can be started and stopped at will. The first tool that comes into mind is the java.util.Timer class, however, even its Javadoc suggest one uses a ScheduledExecutorService instead. If one has to deal with a lot of timed operations, besides of timing out flows, having the control over such signals via a (set of) ScheduledExecutorServices is desirable. Therefore, let's define our timeout API with it: public static Flow.Publisher timeout( Flow.Publisher source, long timeout, TimeUnit unit, ScheduledExecutorService timer) { return new TimeoutPublisher<>(source, timeout, unit, timer); } (Note that if one uses the Executors.newScheduledExecutorService(), it has to be shutdown at some point, otherwise it's non-daemon thread by default would prevent the JVM from quitting.) One primary responsibility of this type of operator is to make sure the ## Java 9 Flow API: mapping and filtering in one stage DevFeed: [Java 9 Flow API: mapping and filtering in one stage]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-09-02T14:33:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Java 9](), [reactive](), [API](), [Library](), [Open Source]() Tags: [backpressure](), [exception](), [flow](), [flow-api](), [java-9](), [publisher](), [reactive](), [reactive-streams](), [rxjava](), [subscriber]() ### AI overview This article examines how to combine mapping and filtering into a single custom operator for Java 9 Flow API publishers. It discusses API design choices, handling mapped, dropped, failed, and completed items, and preserving Reactive Streams backpressure and protocol requirements. ### Source excerpt Introduction In most reactive libraries, mapping and filtering can be done on a flow via separate operators map() and filter() respectively. One rare occasions, the functions to these operators would need to communicate with each other without sharing information in a flow-external manner and without using defer(). Such combined and standard mapFilter() operator doesn't exist and one has to write one of its own. Given that the Java 9 Flow API is brand new, one has to definitely write a custom operator for it as Java 9 itself doesn't provide any rich set of predefined operations on Flow.Publishers unlike its dual, the Stream API. Shameless advertising By the way, if you are looking for a Java 9 Flow-based, native and modern reactive library with rich set of operators, similar to RxJava 2 (even including some operators from its extension project), I happen to have one for you: Reactive4JavaFlow. It is free and open-source with the promising outlook that one day, it may form the basis for the next major RxJava version... MapFilter API design When the Reactive4Java library was first concieved in 2011, the first significant stumbling block was not the lack of lambdas in Java 6/7 but the lack of extension methods. C# had it and made Rx.NET conveniently extendable (assuming you managed to understand how to write operators for it as it wasn't open source at the time). Java still doesn't have any sign of ever getting extension methods, therefore, we either need a rich abstract base class, such as Flowable or Flux, or an utility class whose methods almost look like extension method definitions with the exception that the developer has to stack them on top of one another: import java.util.concurrent.*; import static FlowUtils.*; Flow.Publisher f = timeout( mapFilter( new FlowRange(1, 10, Runnable::run), (v, e) -> { if (v % 2 == 0) { e.next(v.toString()) } if (v == 7) { e.complete(); } } ), 5, TimeUnit.MILLISECONDS ); When thinking about a combined map and filter operat ## RxJava 1 -\> RxJava 2 (Disposing Subscriptions) DevFeed: [RxJava 1 -\> RxJava 2 (Disposing Subscriptions)]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2017-06-21T07:00:00Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [RxJava](), [reactive](), [Streams]() Tags: [androiddev](), [callback](), [memory-leak](), [reactive-streams](), [rxjava](), [subscriber](), [subscription](), [subscriptions]() ### AI overview This continuation post explains how subscription disposal changed from RxJava 1.x to RxJava 2. In RxJava 2, Reactive Streams interfaces and subscriber callbacks provide access to subscriptions for cancellation and lifecycle management, rather than returning a subscription from subscribe methods. ### Source excerpt 2 part series This is a continuation post in a 2 part series: Understanding the changes Disposing subscriptions Disposing Subscriptions # This was the part that I initially found most tricky to grasp but also most important to know as an AndroidDev (memory leak and all). Jedi master Karnok explains this best in the wiki: In RxJava 1.x, the interface rx.Subscription was responsible for stream and resource lifecycle management, namely unsubscribing a sequence and releasing general resources such as scheduled tasks. The Reactive-Streams specification took this name for specifying an interaction point between a source and a consumer: org.reactivestreams.Subscription allows requesting a positive amount from the upstream and allows cancelling the sequence. From that definition alone, it would appear like nothing's changed but that is definitely not the case. In my first post, I pointed out: Publisher.subscribe(Subscriber) => Subscription The use of => vs = was intentional. If you look at the source code for Publisher's subscribe method again, you'll notice a return type of void viz. it doesn't return a Subscription for you to tack on to a CompositeSubscription (which you can then conveniently dispose of onStop/onDestroy). interface Publisher { // return type void (not Subscription like before) void subscribe(Subscriber s); } Karnok again: Because Reactive-Streams base interface, org.reactivestreams.Publisher defines the subscribe() method as void, Flowable.subscribe(Subscriber) no longer returns any Subscription (or Disposable). The other base reactive types also follow this signature with their respective subscriber types. So if you look at the declarations again // RxJava specific constructs // Observable implements "ObservableSource" interface ObservableSource { void subscribe(Observer observer); } // Single implements SingleSource interface SingleSource { void subscribe(SingleObserver observer); } interface CompletableSource { ## RxJava 1 -\> RxJava 2 (Understanding the changes) DevFeed: [RxJava 1 -\> RxJava 2 (Understanding the changes)]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2017-06-21T07:00:00Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [RxJava](), [reactive](), [Programming](), [interfaces]() Tags: [classes](), [continuation](), [flowable](), [gradle](), [import](), [interfaces](), [migration](), [programming](), [reactive](), [reactive-programming](), [reactive-streams](), [rxjava](), [series](), [subscriber](), [subscription]() ### AI overview A migration guide for RxJava 1 users explains the major RxJava 2 changes, including its adoption of the Reactive Streams specification, four core interfaces, and package and Gradle dependency changes. ### Source excerpt In case you haven't heard: RxJava2 was released sometime back. RxJava 2 was a massive rewrite with breaking apis (but for good reasons). Most dependent libraries have upgraded by now though, so you're safe to pull that migration trigger with your codebases. Folks starting out directly with Rx2 might enjoy this guide but it's the ones that started with Rx 1 that will probably appreciate it the most. 2 part series This is a continuation post in a 2 part series: Understanding the changes Disposing subscriptions Let's get started. In this first part, I want to dive into making sense of the Rx2 changes from the point of view of an Rx1 user. Why things changed with RxJava2 # tl;dr- Reactive Streams spec ## Reactive Streams is a standard for doing "reactive" programming and RxJava now implements the Reactive Streams specs with version 2.x. RxJava was sort of a trailblazer in reactive programming land but it wasn't the only library around. There were others that also dealt with reactive paradigms. But with all the libraries adhering to the Reactive Streams spec now, interop between the libraries is a tad bit easier. The spec per say is pretty straightforward with just 4 interfaces: Publisher (anything that publishes events, so Observable,Flowable etc. - more on this later) Subscriber (anything that listens to a Publisher) Subscription (Publisher.subscribe(Subscriber) => Subscription when you join a Publisher and a Subscriber, you are given a connection also called a Subscription) Processor (a Publisher + a Subscriber, sound familiar? yep Subjects for us RxJava 1 luddites) If you're slightly more curious about the design goals, I also suggest the following resources: What's different in 2.0 wiki page - this is really the place I kept coming back to and referencing when I needed to understand the details Fragmented Ep #53 with JakeWharton (forgive the shameless promotion) - ultimate lazy person's guide to understand why/what things changed with RxJava2, as explained by an act ## Java 9 Flow API: asynchronous integer range source DevFeed: [Java 9 Flow API: asynchronous integer range source]() Original publisher: [Read original article]() Author: David Karnok (noreply@blogger.com) Published: 2017-03-05T13:08:00Z Content type: tutorial Language: en Sources: [Akarnokd - Advanced RxJava]() Topics: [Java](), [Java 9](), [reactive](), [interfaces](), [IntelliJ IDEA]() Tags: [asynchronous](), [backpressure](), [coroutine](), [flow](), [flow-api](), [java](), [java-9](), [jdk](), [operator](), [publisher](), [range](), [reactive](), [reactive-streams](), [request-management](), [source](), [submissionpublisher](), [subscriber](), [subscription](), [trampoline](), [varhandle]() ### AI overview A tutorial explores Java 9's Flow API and Reactive Streams interfaces by building an asynchronous integer range Publisher. It discusses composing Publishers, implementing Flow.Subscription, handling subscriber demand, and using IntelliJ 2017.1 EAP while the APIs were non-final. ### Source excerpt Introduction Java 9 is becoming more reactive by introducing the Reactive-Streams interfaces under the parent class java.util.concurrent.Flow, enabling a new standard interoperation between future libraries built on top. There is almost no documentation beyond a underwhelming Oracle documentation and the SubmissionPublisher class' JavaDoc about how to write Publishers, Subscriptions and Subscribers under the Flow API. Plus the Oracle document practically concludes with see RxJava. Indeed, replacing the imports of org.reactivestreams.* with java.util.concurrent.Flow.* in RxJava 2's sources get's one a fully fledged reactive library but there seems to be one crucial expectation with components built on the Flow API: they have to be asynchronous at every stage. I could argue that the underlying concepts work totally fine in synchronous mode, but who am I to question the established definitions? Oh well, if the constraint is to be asynchronous, then let's do it in an asynchronous way. To see what it takes, we could start with a relatively simple source: an asynchronous integer range. Since both Java 9 and the IDE support is in non-final state, I recommend IntelliJ 2017.1 EAP for this "exercise". Asynchronous integer range source Unfortunately, Java 9 won't introduce any standard fluent API entry point with all the well loved map(), filter(), flatMap() etc. operators but one has to build individual Publishers and compose them stage-by-stage. This involves creating a parent Publisher class with the following typical pattern to host the input parameters of the flow to be observed: import java.util.concurrent.*; public final class FlowRange implements Flow.Publisher { final int start; final int end; final Executor executor; public FlowRange(int start, int count, Executor executor) { this.start = start; this.end = start + count; this.executor = executor; } @Override public void subscribe(Flow.Subscriber subscriber) { // TODO implement } } For brevit ## RxConfusions - Part 1 : Map and FlatMap DevFeed: [RxConfusions - Part 1 : Map and FlatMap]() Original publisher: [Read original article]() Author: Manideep Polireddi Published: 2015-12-01T20:10:00Z Content type: tutorial Language: en Sources: [@okmanideep]() Topics: [RxJava](), [function]() Tags: [example](), [map](), [merge](), [rxjava](), [stream](), [subscriber]() ### AI overview This tutorial explains the difference between RxJava's map and flatMap operators through examples. It shows how map transforms emitted items, while flatMap merges items from observables returned by a mapping function and may wait for incomplete observables. ### Source excerpt You probably know what the map operator is. This post discussed mostly about FlatMap and that probably will remove the confusion between map and flatMap operators if any ## RxJava Tip for the Day - Share, Publish, Refcount and All That Jazz DevFeed: [RxJava Tip for the Day - Share, Publish, Refcount and All That Jazz]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2015-01-21T07:00:00Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [RxJava](), [implementation]() Tags: [implementation](), [operator](), [rxjava](), [stream](), [subscriber](), [subscriptions]() ### AI overview This tutorial explains RxJava's share() operator as a wrapper around publish().refcount(). It describes connected observables, multicasting, subscriber coordination, and reference counting during subscription disposal. ### Source excerpt Ok, so in my previous post I innocuously introduced the .share() operator. Observable tapEventEmitter = _rxBus.toObserverable().share(); What is this share operator? ## The .share() operator is basically just a wrapper to the chained call .publish().refcount(). You'll find the chained combo .publish().refcount() used in quite a few Rx examples on the web. It allows you to "share" the emission of the stream. Considering how powerpacked and frequently used this combo is, RxJava basically introduced the friendlier more useful operator share(). This mechanism is sometimes referred to as "multicasting". Let's dig into some of the basics first: "ConnectedObservable" - This is a kind of observable which doesn't emit items even if subscribed to. It only starts emitting items after its .connect() method is called. It is for this reason that a connected obesrvable is also considered "cold" or "inactive" before the connect method is invoked. .publish()- This method allows us to change an ordinary observable into a "ConnectedObservable". Simply call this method on an ordinary observable and it becomes a connected one. We now know what 1/2 of the operator share does. Now why would you ever use a Connected Observable? The docs say: In this way you can wait for all intended Subscribers to subscribe to the Observable before the Observable begins emitting items. This essentially means that a regular usecase for publish would involve more than one subscriber. When you have more than one subscriber, it can get tricky to handle each of the subscriptions and dispose them off correctly. To make this process easier, Rx introduced this magical operator called refcount(): refcount() - This operator keeps track of how many subscribers are subscribed to the resulting Observable and refrains from disconnecting from the source ConnectedObservable until all such Observables are unsubscribed. It essentially maintains a reference counter in the background and accordingly takes the correct