Vavr: Turning Java upside down on the way to 1.0

Javaslang’s changed, man. Tired of being confused as an official Oracle offering, the functional library for Java 8 switched names to the all cool Vavr. Why? Take a look below and see for yourself.

In addition to their rebranding scheme, Vavr has taken the dramatic step of rebooting their whole version numbers. This negative version jump from Javasland 3.0 to Vavr 0.9 was meant to show a fresh, clean start.

So, what can we expect from Vavr?

Things are always a little chaotic when there’s a big change like this. So, keeping their ears to the ground, the Vavr team has collected feedback to see what the community wants and need. Here are some of their new goals and benchmarks, in no particular order:

• the ability to choose features, also related to integration of new features and the footprint
• interoperability with Java, especially the collections and name conflicts
• backward compatibility, also related to seamless version upgrades
• adoption of future Java features, e.g. modularization and value types
• better documentation

Modularization

Not the dreaded modules! Well, maybe. Vavr is aiming to join the crowd of technologies taking advantage of modular architecture.

According to Daniel Dietrich, the creator of Vavr, “From the user perspective, slicing Vavr’s main library into several modules helps to select features. We gain the freedom to choose and have better control over the footprint.”

Modules are intended to help the contributors in terms of maintainability and visibility. This allows dependencies between features to become less obscure and reduce overall complexity, leading to optimized build times, faster test iterations, and more. This is clearly a result of the upcoming Java 9 modules.

SEE MORE: Java 9 and the future of modularity: Will Project Jigsaw be a hit or flop?

However, slicing Vavr into smaller modules will break backwards compatibility. This is one of the issues that they want to fix before the 1.0 release. Additionally, the Vavr main modules themselves are currently under discussion. Nothing is set in stone, so if you want to contribute to the discussion, head on over to their GitHubto add your two cents.

At its core, Vavr offers functions, tuples and an interface Value that is the common type of most Vavr classes. Beside these, the core will contain Lazy(laziliy evaluated values) and two popular and widely used controls, Option(null-safety) and Try (error-handling).

We can’t change the Java language by ourselves. All features that try to do so, e.g. pattern matching and for comprehensions, will be moved to a separate module vavr-api. Because different Java 9 modules can’t export the same package, the packagename needs to be changed.

Interoperability

The Java ecosystem is a big place. So, a Java library needs to work with a lot of different systems.

The folks at Vavr have kept the naming scheme of old-school Java collections for persistent collections. However, because of overlapping collection names, users need to fully qualify class names. Vavr is looking for a prefix to help rename the collections. Again, your two cents would be welcome.

SEE MORE: Top 9 improvements and features in Java 9

Daniel Dietrich, again:

“Frequently someone asks why our persistent collections do not implement the standard Java collection interfaces. This is still a no-go. Our users would suffer because it would mix the functional paradigm (changes return new versions) and the imperative paradigm (changes perform side-effects or throw).

We already have an answer to this kind of interoperability. We provide standard Java collection views. Instead of copying the collection elements, we are able to create a view in constant time and memory. For the case that a native Java collection instance is needed, we provide several conversion methods.

Renaming our collections should solve the last interoperability issue.”

Backward compatibility

Backward compatibility is an issue that not even semantic versioning can solve. Not even Java 9’s modules will be able to solve this entirely. So, the only reliable solution is to repackage dependencies during the build phase. It is what it is.

Looking beyond Java 9

There’s a lot going on in Java 9 other than Jigsaw, we swear. For instance, Vavr is excited about pattern matching, value types, and primitive generics. Mostly because these features will allow them to improve the cpu and memory consumption of our types and remove workarounds for missing language features. No matter how long it takes these features to ship, Vavr is going to try and be ready when they do.

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!