Making moves towards the next stage of Vavr

On the road to Vavr 1.0: Breaking changes and dismantling the core API

Jane Elizabeth
© Shutterstock / Ilkin Zeferli

What’s up with Vavr? The functional library formerly known as Javaslang is on the path to 1.0. Along the way, we’re going to run into some pretty big changes, including breaking backwards compatibility with previous versions.

Vavr is on the way to a whole new library. But, the way forward does include an awful lot of changes for the functional library formerly known as Javaslang. For one thing, Vavr is going to go simple. As time goes by, Vavr will be reduced as the “slang” is adapted by the “host language”.

Vavr is taking this opportunity to go all out and redesign the type hierarchy from scratch. This means that there will be breaking changes for backwards compatibility.

The simplicity of Vavr

Vavr’s new design principle is simplicity. At all costs.  To that end, they have removed interfaces like Lambda, Tuple, Function0..8, and Tuple0..8.


While these functions are not necessary for Vavr, this does have serious implications for its pattern matching APIs and comprehensions. Especially since native pattern matching is definitely a part of Java’s future.

In the future, the collection package will only contain the core collections. Vavr may be moving to a smaller collection type hierarchy focusing on sequences and maps, moving away from the large collection type hierarchy seen in JavaScript and TypeScript. Additional collections will be packaged in a separate module.

SEE MORE: Vavr: Turning Java upside down on the way to 1.0


We do have to address the elephant in the room: Java 9. Not a lot of developers are adopting native Java 9 right now for whatever reason. And that means supporting native Java 9 modularization is going to be difficult if Vavr is still supporting Java 8.

What to do? Well, one option is taking the decision away from the users and have Vavr 1.0 only support Java 9+. Java 8 users can continue to use Vavr 0.9x. But we’ll see how that goes.

Dismantling the core API

The core API isn’t going unchanged, either. As the Vavr team is moving towards a more simplified type hierarchy, features like tuples and n-ary functions aren’t properly integrated with the rest of the Java languages. In particular, n-ary types don’t scale well. Code generators are needed to tackle this kind of maintenance complexity.

Vavr’s maximum arity of eight is no longer sufficient for a number of cases, including validation type. To solve this, Vavr wants to get rid of the code generator entirely.

Additionally, by cutting down on function types, it reduces complexity. Instead of a supporting long list of all kinds of checked functions, Vavr will only support the signatures that can’t be expressed in other ways.

SEE MORE: Java 10 is finally here! A closer look at the new features

A work in progress

If you’re interested in seeing the latest evolution of Javaslang, head on over to Vavr and check out the shiny new changes. They’re looking for input for the 1.0 release version and want to hear from you!

Jane Elizabeth
Jane Elizabeth is an assistant editor for

Inline Feedbacks
View all comments