Devvalley Java Meetup

Two sessions were being given at the java dev meeting on the 26th of September 2019, at OpenWeb^{1 2} in Nieuwegein.

I just thought I'd write some of the things down that were being explained.

Reactive Streams

The first session, provided by Tim van Eijndhoven, was very interesting.

One of the limitations of the Stream API of Java, is that there is no implementation for "back pressure", i.e. the consumer of the stream cannot indicate to the producer of the stream the chunk size of the work it can handle.

Several implementations of reactive streams are already available.

• RxJava (I noticed it looks a lot like RxJs, and no wonder. It is both based on Reactive Extentions³.)
• Project Reactor⁴
• Akka Streams⁵

RxJava

It still targets java 6, which makes it very suitable for android development, where it is very popular.

It's used by the Vert.x framework.

Project Reactor

A newcomer available from Pivotal. It's built on Java 8, on version 3 and is used by spring.

Has a feature to pass context.

Akka Streams

Akka Streams is from Lightbend, and is part of Akka. A framework built around Scala.

It seems to be quite different compares to the other two implementations.

There is an Alpakka Library, containing integrations with other systems, for example ElasticSearch, MongoDb, AWS APIs, etc.

Reactive Streams in Java⁶

Apparently there is already an active JEP (JEP 266) to get Reactive Streams into Java 9.

The different interfaces are called Flow.Publisher, Flow.Subscriber, Flow.Subscription and Flow.processor.

The existing implementations mentioned above all already have functionality to proxy their classes into the Java 9 interfaces.

Some notes

The Publisher is responsible for making decisions regarding what data to send to the Subscribers. For instance to skip data or to send all old data as soon as the subscriber subscribes.

And of course because of the "back pressure" thing, a publisher will have to keep track of how many items has been sent to the subscribers, and how many the subscriber can still receive before the publisher needs to wait for the next request.

The difference seems to be between cold streams and hot streams.

Where cold streams, a new subscriber will receive the same stream, starting from the beginning.

Where hot streams, data that has passed, will not be sent to new subscribers. Ideal for quickly changing values, where the recent value is the most valuable.

Testing is hard, because it's asynchronous. All the frameworks provide ways of adding unit tests.

Frameworks provide performance via:

• macro fusion: replacing subsequent operators with a single operator
• micro fusion: share resources or internal structure between operators.

The reactive stream interfaces are easy, but hard to get right frameworkwise.

The learning curve is pretty steep, though.

There are two points, usually, in the stream where you can decide to fiddle with thread-usage.

Supercharged Microservices

The second speaker was Dave Franken.

The second session was regarding the use of Kotlin⁷, and GraalVM⁹ and Quarkus⁸ to supercharge your microservices, making them both small (memory wise), with very fast bootup times (seriously very fast!), and can be developed quickly in Kotlin.

That is basically all I have to say about that.

References

[1] Devvalley 2019 - Open source meetup of the future

https://devvalley.openweb.nl/

[2] Devvalley Java Meetup

https://www.meetup.com/nl-NL/Devvalley/events/261802586/

[3] Reactive

http://reactivex.io/

[4] Project Reactor

https://projectreactor.io/

[5] Akka Streams

https://doc.akka.io/docs/akka/current/stream/index.html

[6] JEP 266: More Concurrency Updates

https://openjdk.java.net/jeps/266

[7] Kotlin Programming Language

https://kotlinlang.org/

[8] Quarkus - Supersonic Subatomic Java - A Kubernetes Native Java stack tailored for GraalVM & OpenJDK HotSpot, crafted from the best of breed Java libraries and standards

https://quarkus.io/

[9] GraalVM Run Programs Faster Anywhere

https://www.graalvm.org/