On the road to Vavr 1.0: Breaking changes and dismantling the core API
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.
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.
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!