The introduction of CompletableFutures in Java 8 brought to the language features available in the scala.concurrent.Future such as monadic transformations.
What are the differences, and why a Scala developer should prefer Scala Futures over java 8 CompletableFuture ?
Are there still good reasons to use the scala.concurrent.Futurein Java through akka.dispatch bridge?
What are the differences, and why a Scala developer should prefer Scala Futures over java 8 CompletableFuture ?
Rephrasing what #dk14 pointed out in comments I'd say that CompletableFuture doesn't have idiomatic Scala api.
For scala developer the implications are:
lack of for comprehensions due to fact that it does not follow Scala method conventions common for monadic types
java-scala interop overhead needed when using big part of it's methods
It is also worth noting that java CompletableFuture is not exactly equivalent of scala Future. It is rather a fuse of scala Future and Promise.
Considering the cons listed above there isn't much sense in using CompletableFuture in scala unless you are designing public api that should be seamlessly interoperable with java.
Are there still good reasons to use the scala.concurrent.Future in Java through akka.dispatch bridge?
I am particularly looking for reasons to use akka.dispatch in Java, if there are still any
Akka is build on top of scala and it sometimes uses scala Futures. This means that in cases when you have some portion of code written in java it is worth to wrap it in scala api (with akka.dispatch java api) to be able to easily use it with akka.
For example, you are implementing akka actor in java. When processing message you want to do some non-blocking reading that, when done, should produce result as a message to another actor.
What you could do is to put your I/O into java Callable, then use akka.dispatch.Futures#future to get scala Future out of it, and then you could leverage akka pipe to make result of the future be delivered as a message to some actor.
Related
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.
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.
As part of a study I am doing, I am exploring the supposed simplicity of using languages like Scala & Clojure to achieve concurrency on the JVM.
By simplicity, I am hoping to prove that these languages provide easier concurrency constructs than what Java 7 provides.
Therefore, I am hoping to find some good references that explain the complexities of Java's concurrency model.
Outside of pointing me in the direction of Google (which I have already searched with limited success), I would appreciate if those in-the-know could provide me with some good references to get me started off in this area.
Thanks
Java does not support lambda expressions. Creating an inline callback (eg, for the completion of an asynchronous call) requires 5 lines of boilerplate for an anonymous type.
This strongly discourages people from using callbacks. This is probably why Java 7 still does not have an interface for a callback that takes a value (as opposed to Runnable and Callbable), whereas C# has had one since 2005.
Therefore, the JDK does not have any real support for asynchronous operations.
The key to an asynchronous operation is the ability to kick off a long-running request, and have it run a callback when it finishes, without consuming a thread for the duration of the request. In Java, you can only do this by making a separate thread call get() on a Future<V>. This limits the concurrency of an application using the standard API to the number of threads you can sanely support.
To solve this problem, Google's Guava framework for better Java code introduces a ListenableFuture<V> interface which does have completion callbacks.
Languages like Scala fix this problem by supporting lambda expressions (which compile to anonymous classes) and adding their own Promise / Future types.
While higher level languages are easier to use multiple cores, what is often forgotten is why you want to use multiple cores which is to make the program faster e.g. increase its throughput.
When you consider options which increase concurrency, you need to test whether these options actually improve performance in some way. (Because very often they don't)
e.g. STM (Software Transactional Memory) makes it easier to write multi-threaded applications without having to worry about concurrency issues. The problem is that for trivial examples, it would be faster to not use STM and only use one thread.
Using multiple threads adds complexity and makes your application more fragile, so there has to be a good reason to do it otherwise you should stick to the simplest solution possible.
For more discussion
http://vanillajava.blogspot.co.uk/2011/11/why-concurency-examples-are-confusing.html
How can scala make writing multi-threaded programs easier than in java? What can scala do (that java can't) to facilitate taking advantage of multiple processors?
The rules for concurrency are
1 avoid it if you can
2 share nothing if you can
3 share immutable objects if you can
4 be very careful (and lucky)
For rule 2 Scala helps by providing a nicely integrated message passing library out of the box in the form of the actors.
For rule 3 Scala helps to make everything immutable by default.
For rule 4 Scala's flexible syntax allows the creation of internal DSL's making it easier and less wordy to express what you need consicely. i.e. less place for surprises (if done well)
If one takes Akka as a foundation for concurrent (and distributed) computing, one might argue the only difference is the usual stuff that distinguishes Scala from Java, since Akka has both Java and Scala bindings for all its facilities.
There is nothing Scala does that Java does not. That would be silly. Scala runs on the same JVM that Java does.
What Scala does do is make it easier to write, easier to reason about and easier to debug a multi-thread program.
The good bits of Scala for concurrency are its focus on immutable objects, its message-passing and its Actors.
This gives you thread-safe read-only data, easy ways to pass that data to other threads, and easy use of a thread pool.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am a Java developer and I want to know how I can use Scala in my Java programs?
Go read Daniel Spiewak's excellent blog series about Scala. With Scala you can keep:
all your Java libraries
all the advantages of running on a JVM (ubiquity, administrative tools, profiling, garbage collection etc)
But you can write Scala code:
more concise and clear than Java (especially using more functional style, such as in the collections library)
it has closures and functions as part of the language
it has operator overloading (from the perspective of usage)
it has mixins (i.e. interfaces which contain implementation)
Also, take a look at this recent news item post on Scala's site:
"Research: Programming Style and Productivity".
In his paper, Gilles Dubochet, describes how he investigated two aspects of programming style using eye movement tracking. He found that it is, on average, 30% faster to comprehend algorithms that use for-comprehensions and maps, as in Scala, rather than those with the iterative while-loops of Java.
And another key quote from the news item:
Alex McGuire, who writes mission critical projects in Scala for power trading companies, says of Scala "The conciseness means I can see more of a program on one screen. You can get a much better overview. When I have some mathematical model to write with Java I have to keep two models in my head, the mathematical model itself and the second a model of how to implement it in Java. With Scala one model, the mathematical one, will do. Much more productive.”
You an read the rest of the post and other linked items there.
UPDATED 2019
I can name some simple points in plain language from my limited experience:
Properties. C++ and Java had this notion of a public getter/setter function "property" wrapped around an internal class variable which led to large amounts of boilerplate code. C# formalized this as a real language feature and reduced much of the boilerplate in C# 3.0 with auto-implemented properties. Scala classes define trivial properties simply as regular read only vals or read/write vars. The class may later choose to replace those with get or get/set methods without affecting client code. For this, Scala provides the most elegant solution with the least language features and complexity.
Arrays use regular generics. In Java/C#, int[] is redundant and confusing vs List<int> or List<Int>. Worse, in Java, List<Int> has lots of runtime overhead, so many developers have to know to use int[]. Scala avoids that problem. Also, in Java/C#, arrays support (covariant) casting, which was a mistake, that they now can't fix because of legacy concerns.
Scala has better support for immutability. val is a basic language feature.
Scala lets if blocks, for-yield loops, and code in braces return a value. This is very elegant in many situations. A very small plus is that this eliminates the need for a separate ternary operator.
Scala has singleton objects rather than C++/Java/C# class static. This is a cleaner solution.
Pattern matching. Object unpacking. Very nice in a large numbers of situations.
Native tuples.
"case classes" which are what most other languages would call record types or named tuples.
Fancier standard library with more elegant collections.
Multi-line strings. String interpolation formatting.
Optional semi-colons.
Cons.
Java has caught up a lot. Java 8 was first released in 2014, but it took several years for older Java versions to be phased out and the new Java 8 features to be fully used across the Java ecosystem. Now, lambdas and closures and basic functional collections, with support for filter/map/fold are quite standard for the Java ecosystem. More recently, Java has added basic var local variable type inference and has multi-line strings and switch expressions in release builds preview mode.
Scala is complicated. I'd highlight features like implicits to be inherently confusing.
Scala has minimal backward compatibility. Scala 2.10 artifacts are incompatible with Scala 2.11.
Building a Java API for other JVM-language developers like Scala or Clojure or Kotlin is normal, well supported and accepted. You generally don't want to build APIs in Scala that cater to non-Scala developers.
I am not sure you can easily use Scala in your Java programs, as in "call a Scala class from a Java class".
You can try, following the article "Mixing Java and Scala".
Relevant extracts:
The problem is that the Java and Scala compilation steps are separate: you can't compile both Java and Scala files in one go.
If none of your Java files reference any Scala classes you can first compile all your Java classes, then compile your Scala classes.
Or, if none of your Scala files reference any Java classes you can do it the other way around.
But if you want your Java classes to have access to your Scala classes and also have Scala classes have access to your Java classes, that's a problem.
Scala code can easily call directly into Java code, but sometimes calling Scala code from Java code is trickier, since the translation from Scala into bytecode is not quite as straightforward as for Java:
sometimes the Scala compiler adds characters to symbols or makes other changes that must be explicitly handled when calling from Java.
But a Scala class can implement a Java interface, and an instance of that class can be passed to a Java method expecting an instance of the interface.
The Java class then calls the interface methods on that instance exactly as if it were a Java class instance.
The opposite is possible, of course, as described in Roundup: Scala for Java Refugees, from Daniel Spiewak.
Scala or Java:
Pros:
Scala supports both functional and imperative OO programming styles and it advocates that both models are not conflicting with each other but yet they are orthogonal and can complement each other. Scala doesn't require or force the programmer to use a particular style, but usually the standard is to use functional style with immutable variables when appropriate (there are several benefits of using the functional approach such as concise and short syntax and using pure functions usually reduces the amount of non-determinism and side-effects from the code), while resorting to imperative programming when the code would look simpler or more understandable.
Scala doesn't require ; at the end of each line having it optional which leads to cleaner code
In Scala functions are first class cititzens
Scala supports some advanced features which are directly built in the language such as: Currying, Closures, Higher order functions, pattern matching, Higher Kinded Types, Monads, implicit params.
Scala can interact very well with Java and both can coexist. It is possible to use java libraries directly inside Scala code invoking Java classes from scala code.
Has Tuples built in the language which makes life easier in several scenarios
Supports operator overloading
has a rich Ecosystem and some popular open source projects in Apache are based on it.
Async and Non-blocking code is very easy to write with Scala Futures
Scala supports the Actor model using Akka which can be highly efficient and scalable when running distributed applications in multi-threaded and parallel business use cases (Enforce encapsulation without resorting to locks, State of actors is local and not shared, changes and data is propagated via message)
Code tends to be shorter if compared to Java (might not be always the case)
Cons:
Steep learning curve if compared to Java and other languages, requires more time in general from the learner to understand all the concepts clearly. Has many features
It is not as well established as Java in the market since it was invented later so Java in overall is more mature and more battle-tested.
Scala opens too many doors. It allows a lot of complex syntax that if used in a irresponsible way might lead to code that is hard to understand.
Abusing things such as operator overloading, implicit params and other constructs can be counter-productive and might ruin code legibility.
Java is also evolving and still getting better with newer versions (such as with JDK 9 modules)