It seems on every iteration of Java for the last few major releases, there are consistently new ways to manage concurrent tasks.
In Java 9, we have the Flow API which resembles the Flowable API of RxJava but with Java 9 has a much simpler set of classes and interfaces.
Java 9
Has a Flow.Publisher, Flow.Subscriber, Flow.Processor, Flow.Subscription, and SubmissionPublisher, and that's about it.
RxJava
Has whole packages of Flow API-like classes, i.e. io.reactivex.flowables, io.reactivex.subscribers, io.reactivex.processors, io.reactivex.observers, and io.reactivex.observables which seem to do something similar.
What are the main differences between these two libraries? Why would someone use the Java 9 Flow library over the much more diverse RxJava library or vice versa?
What are the main differences between these two libraries?
The Java 9 Flow API is not a standalone library but a component of the Java Standard Edition library and consists of 4 interfaces adopted from the Reactive Streams specification established in early 2015. In theory, it's inclusion can enable in-JDK specific usages, such as the incubating HttpClient, maybe the planned Async Database Connection in parts, and of course SubmissionPublisher.
RxJava is Java library that uses the ReactiveX style API design to provide a rich set of operators over reactive (push) dataflows. Version 2, through Flowable and various XxxProcessors, implements the Reactive Streams API which allows instances of Flowable to be consumed by other compatible libraries and in turn one can wrap any Publisher into a Flowable to consume those and compose the rich set of operators with them.
So the Reactive Streams API is the minimal interface specification and RxJava 2 is one implementation of it, plus RxJava declares a large set of additional methods to form a rich and fluent API of its own.
RxJava 1 inspired, among other sources, the Reactive Streams specification but couldn't capitalize on it (had to remain compatible). RxJava 2, being a full rewrite and a separate main version, could embrace and use the Reactive Streams specification (and even expand upon it internally, thanks to the Rsc project) and has been released almost a year before Java 9. In addition, it was decided both v1 and v2 keeps supporting Java 6 and thus a lot of Android runtimes. Therefore it couldn't capitalize directly on the Flow API provided now by Java 9 directly but only through a bridge. Such bridge is required by and/or provided in other Reactive Streams-based libraries too.
RxJava 3 may target the Java 9 Flow API but this hasn't been decided yet and depending on what features the subsequent Java versions bring (i.e., value types), we may not have v3 within a year or so.
Till then, there is a prototype library called Reactive4JavaFlow which does implement the Flow API and offers a ReactiveX style rich fluent API over it.
Why would someone use the Java 9 Flow library over the much more diverse RxJava library or vice versa?
The Flow API is an interoperation specification and not an end-user API. Normally, you wouldn't use it directly but to pass flows around to various implementations of it. When JEP 266 was discussed, the authors didn't find any existing library's API good enough to have something default with the Flow API (unlike the rich java.util.Stream). Therefore, it was decided that users will have to rely on 3rd party implementations for now.
You have to wait for existing reactive libraries to support the Flow API natively, through their own bridge implementation or new libraries to be implemented.
Providing a rich set of operators over the Flow API is only reason a library would implement it. Datasource vendors (i.e., reactive database drivers, network libraries) can start implementing their own data accessors via the Flow API and rely on the rich libraries to wrap those and provide the transformation and coordination for them without forcing everybody to implement all sorts of these operators.
Consequently, a better question is, should you start using the Flow API-based interoperation now or stick to Reactive Streams?
If you need working and reliable solutions relatively soon, I suggest you stick with the Reactive Streams ecosystem for now. If you have plenty of time or you want to explore things, you could start using the Flow API.
At the beginning, there was Rx, version one. It was a language agnostic specification of reactive APIs that has implementations for Java, JavaScript, .NET. Then they improved it and we saw Rx 2. It has implementations for different languages as well. At the time of Rx 2 Spring team was working on Reactor — their own set of reactive APIs.
And then they all thought: why not make a joint effort and create one API to rule them all. That was how Reactive Commons was set up. A joint research effort for building highly optimized reactive streams compliant operators. Current implementors include RxJava2 and Reactor.
At the same time JDK developers realized that reactive stuff is great and worth including in Java. As it is usual in Java world the de facto standard become de jure. Remeber Hibernate and JPA, Joda Time and Java 8 Date/Time API? So what JDK develpers did is extracting the very core of reactive APIs, the most basic part, and making it a standard. That is how j.u.c.Flow was born.
Technically, j.u.c.Flow is much more simpler, it consists only of four simple interfaces, while other libraries provide dozens of classes and hundreds of operators.
I hope, this answers the question "what is the difference between them".
Why would someone choose j.u.c.Flow over Rx? Well, because now it is a standard!
Currently JDK ships with only one implementation of j.u.c.Flow: HTTP/2 API. It is actually an incubating API. But in future we might expect support of it from Reactor, RxJava 2 as well as from other libraries, like reactive DB drivers or even FS IO.
"What are the main differences between these two libraries?"
As you noted yourself, the Java 9 library is much more basic and basically serves as a general API for reactive streams instead of a full-fledged solution.
"Why would someone use the Java 9 Flow library over the much more diverse RxJava library or vice versa?"
Well, for the same reason people use basic library constructs over libraries - one less dependency to manage. Also, due to the fact that the Flow API in Java 9 is more general, it is less constrained by the specific implementation.
What are the main differences between these two libraries?
This mostly holds true as an informative comment(but too long to fit in), the JEP 266: More Concurrency Updates responsible for the introduction of the Flow API in Java9 states this in its description(emphasis mine) -
Interfaces supporting the Reactive Streams publish-subscribe
framework, nested within the new class Flow.
Publishers produce items
consumed by one or more Subscribers, each managed by a Subscription.
Communication relies on a simple form of flow control (method
Subscription.request, for communicating back pressure) that can be
used to avoid resource management problems that may otherwise occur in
"push" based systems. A utility class SubmissionPublisher is provided
that developers can use to create custom components.
These (very
small) interfaces correspond to those defined with broad participation
(from the Reactive Streams initiative) and support interoperability
across a number of async systems running on JVMs.
Nesting the interfaces within a class is a conservative policy allowing
their use across various short-term and long-term possibilities. There
are no plans to provide network- or I/O-based java.util.concurrent
components for distributed messaging, but it is possible that future JDK
releases will include such APIs in other packages.
Why would someone use the Java 9 Flow library over the much more diverse RxJava library or vice versa?
Looking at a wider prospect this is completely opinion based on factors like the type of application a client is developing and its usages of the framework.
Related
Google search gives me, 'The Collection in Java is a framework...'. Further search gives me, 'The key difference between a library and a framework is "Inversion of Control"'. I reckon in Collection's context, framework is not used in the sense of IoC. Please enlighten.
The main difference between Library and Framework is:
Library = Set of useful components
Framework = Set of useful components + Utilities to use the components
Library is a set of reusable components.
It provides flexibility to the user on the way in which the components can be called or used.
A real-world analogy of Library:
Traditional City Taxi service is like a library.
Taxi can be called by waving hand, or by shouting 'Taxi...', or by calling a telephone number.
Framework is a Library that comes packaged along with some utilities for using the library.
Framework provides an extra benefit, by offering an efficient built-in way of using the components.
A real-world analogy for framework:
A Taxi service that comes with its own app is like a framework.
The Taxi cannot be called by waving hand or shouting 'Taxi...'.
Taxi can be booked only by using the app.
Java Collections is labeled as a framework, instead of as a library, because it comes with some useful implementations of algorithms (sorting, queue management, etc) along with the set of useful components (List, Set, HashMap, etc).
For example, Java Collections Framework provides an efficient built-in algorithm for sorting objects.
The programmer can choose to either use the built-in sorting utility or write a new algorithm.
As the built-in algorithms are provided along with components, Java Collections is considered a framework, rather than just a library.
A "framework" doesn't imply IoC.
The term is not well-defined, proven by the fact that you can find different definitions online.
E.g. techterms.com says:
A framework, or software framework, is a platform for developing software applications. It provides a foundation on which software developers can build programs for a specific platform. For example, a framework may include predefined classes and functions that can be used to process input, manage hardware devices, and interact with system software. This streamlines the development process since programmers don't need to reinvent the wheel each time they develop a new application.
The "Java Collections Framework" is a good "foundation for building programs". That's all it means.
How does the CompletableFuture introduced in JDK 8 compare with the io.netty.util.concurrent.Future provided by Netty ?
Netty documentation mentions that
JDK 8 adds CompletableFuture which somewhat overlaps
io.netty.util.concurrent.Future
http://netty.io/wiki/using-as-a-generic-library.html
The questions I'm trying to get answers to are:
What would their similarities and differences be?
How would the performance characteristics of the two differ? Which one would be able to scale better?
With respect to the similarities/ differences, I have been able to come up with the following:
Similarities:
The fundamental similarity being that both are non-blocking as compared to the Java Future. Both the classes have methods available to add a listener to the future, introspect failure and success of the task and get results from the task.
Differences:
CompletableFuture seems to have a much richer interface for things like composing multiple async activities etc. Netty's io.netty.util.concurrent.Future on the other hand allows for multiple listeners to be added to the same Future, and moreover allows for listeners to be removed.
If we look at that whole paragraph (especially the first sentence)
Java sometimes advances by adopting ideas that subsume constructs
provided by Netty. For example, JDK 8 adds CompletableFuture which
somewhat overlaps io.netty.util.concurrent.Future. In such a case,
Netty's constructs provide a good migration path to you; We will
diligently update the API with future migration in mind.
What it's basically saying is that the netty Future and CompletableFuture are the same concept, but implemented at different times by different people.
Netty made their future because there wasn't one available in java, and they didn't want to pull one in as a dependency from something like Guice. But now, java has created one, and it's available for use.
In the end of the paragraph they're basically saying that the netty API may replace Future with CompletableFuture in the future.
As far as similarities/differences, they're both just one of many implementations of the future/promise pattern. Use the netty one when you're using the netty api and netty specific stuff, otherwise use CompletableFuture.
I'm learning about Google App Engine and Googles datastore from here and they keep mentioning "low-level Java API."
What exactly is a "low-level Java API" and how does it differ from a "high-level Java API" (which I assume must also exist since there is a low-level one?"
Google searches yielded poor results for this question.
Let us first see what documentation says about this -
The Java Datastore SDK provides a supported low-level API for the Datastore. In the documentation for the Datastore we use this low level API for the sake of simplicity.
However, for your convenience, the Java SDK also includes third-party implementations of the Java Data Objects(JDO) and Java Persistence API (JPA) interfaces. Note that these are provided for your convenience only; they are not supported by Google.
In addition, the Java SDK includes other third party frameworks designed to simplify Datastore usage for Java developers.
When somebody refers to low-level and high-level, they usually talk about abstraction level.
Abstraction
is a technique for managing complexity of computer systems. It works by establishing a level of complexity on which a person interacts with the system, suppressing the more complex details below the current level. The programmer works with an idealized interface (usually well defined) and can add additional levels of functionality that would otherwise be too complex to handle.
To give direct example, language C offers you lower level API to computer resources than Java. In C it is possible to do garbage collection in real time at will of programmer, however it is most likely that majority programmers will shoot themselves in a foot with this than get concrete benefits.
In other words, google offers you officially low level API which is powerful but not as trivial to use. There are third party solutions which abstract google's low level API into high-level API and make it simpler to use the API.
Simply put, a low-level application programming interface (API) is generally more detailed and hence allows you to have more detailed control to manipulate functions within them on how to use and implement them while a High-level API is usually more generic and relatively simpler and provides more functionality within one command statement than a lower-level API. High-level interfaces are comparatively easier to learn and to implement the models using them. They allow you to write code in a shorter amount of time and to be less involved with the details.
Hope it helps to get the general idea.
My requirement is that I am looking for an light weight event framework which is compatible in Android and Java Fx( Windows and Linux platform) so that it runs seamless in both the technologies.
I researched for existing event based frameworks.
1) Eventing framework mbassador (by bennidi)-> is it compatible with android 4.0 (Ice Cream sandwich)
as it works fine with javafx and is lightweight and performance is also good.
2) Guava EventBus :- From documentation it seems it is compatible with android but what about performance and is it better then mbassador.
Eventing framework MBassador is compatible with Android 4.0.
Guava Event Bus is lightweight and also compatible with both the technologies.
Both the above framework are lightweight and provide robust mechanism for Subscribe/Publish pattern and according to description of MBassador it's initial design was inspired from Guava Event Bus but the Strong reference to listeners used in Guava Event Bus was problem in some scenario.
According to credits section in description at GitHub MBassador
The initial inspiration for creating this component came from trying out Google Guava's event bus implementation. I liked the simplicity of its design and I do trust the developers at Google a lot, so I was happy to find that they also provided an event bus system. The main reason it proved to be unusable for our scenario was that it uses strong references to the listeners such that every object has to be explicitly deregistered. This was difficult in our Spring managed environment. Finally, I decided to create a custom implementation, which then matured to be stable, extensible and yet very efficient
Both the framework are robust, lightweight and it depends on your requirement which one to use.
I have found performance comparison on [Java event bus library comparison]](http://codeblock.engio.net/?p=37) (I got the results from google cached page of this site) where Google Guava, SimpleBus, EventBus and mbassador frameworks were compared and MBassador was the clear winner.
EDIT: I removed the picture snapshot and just focusing on end results,
The shown performance characteristics of the compared implementations indicate that,
1. Listener subscription is an expensive operation for all implementations but MBassador and Guava
2. Concurrent access does generally slow down the bus performance because of higher
contention/synchronization.
3. SimpleBus is by far the slowest implementation.
4. MBassador is by far the fastest implementation in all
scenarios. It also offers the best scaling characteristics meaning that higher concurrency rates do not slow down the bus performance as much as the others. This is because MBassador relies on a custom data structure with very fast write operations that do not block readers and at the same time do not copy existing data structures (most other implementations use CopyOnWriteArrayList).
To sum it up For the past few months we have been using MBassador and it holds up to our requirement it is working well in Android, JavaFX and works well in simple java too on Linux, Windows, Mac etc O.S.
I know that there is a supported Scala DSL for Camel. Apart from that
Is it realistic to replace Java (the language) completely by Scala for a Camel based project?
Which kind of known problems are known to exist?
Which workarounds exist for those problems (other than using Java)?
I am mainly looking for less boilerplaty code.
Akka offers stable Scala-idiomatic Camel integration.
The akka-camel module allows actors,
untyped actors and typed actors to
receive and send messages over a great
variety of protocols and APIs. This
section gives a brief overview of the
general ideas behind the akka-camel
module, the remaining sections go into
the details. In addition to the native
Scala and Java actor API, actors can
now exchange messages with other
systems over large number of protcols
and APIs such as HTTP, SOAP, TCP, FTP,
SMTP or JMS, to mention a few. At the
moment, approximately 80 protocols and
APIs are supported.
Apart from that, I'm sure this replacement is possible due to a good interop, and there could hardly be any Scala-specific issues that are not peculiar to Java. E.g., Akka Actors used for publishing to/consuming from Camel endpoints are based on java.util.concurrency, and the only problem I can think of is a fixable bug in the library.
In the meantime a relatively simple Scala DSL has been developed for Camel, that should have the functionality of the Java DSL.
To decide if it is realistic for you, consider:
- The quality of the IDE support for the languages
- The Scala language complexity
- The Scala/Java language popularity
- DSL extension possibilities. In Scala, it should be possible (with some Scala magic) to to extend the DSL (add additional DSL elements)
If you decide to try it out, it would be great if you share your experience with the Apache Camel community your impressions on:
code readability, code maintainability, code efficiency, developer satisfaction, code size, the number of "man-days".
Since then (2010-2011), there is now (Sept 2016) a recent initiative named for Akka Streams Integration, codename Alpakka.
We believe that Akka Streams can be the tool for building a modern alternative to Apache Camel. That will not happen by itself overnight and this is a call for arms for the community to join us on this mission. The biggest asset of Camel is its rich set of endpoint components. We would like to see that similar endpoints are developed for Akka Streams.
See "akka/akka-stream-contrib".