Vavr Roadmap

[pivovarit]

Hi! It took me a while to fully immerse and comprehend the context and I’m ready to present some ideas for the future of Vavr. While it might feel rather slow, I’d rather do it too slow, then make hasty decisions while not really understanding the full context.

Expectation and change management is an incredibly tricky thing to do - especially in the world of widely-adopted OSS libraries - and context is king.

Current context:

• v0.10.5 is near-feature-complete: while we could always add more things or move things around, core functionality is there and does the job it was designed for
• vavr was stale for a while: v0.10.4 was released in July 2021, v0.10.5 in 2024
• vavr is Java 8 based
• “aligning to Scala” is no longer as attractive as it used to be

The future of Vavr embodies three streams of work:

• what happens with the current 0.x
• when/what will be the baseline for 1.x
• future and ambitious goals for 2.x

As of today, my proposal is to:

• keep 0.x in maintenance mode as its effectively been during last couple of years, throw in a couple of extras, and release as 0.11.0 - I’d be still open to merging and releasing pull requests, though (the automation we built makes releases a breeze)
• use the latest 0.x release as baseline of 1.x with a major JDK requirement update (17 or 21) and apply selective cherry-picking of work that went into 1.0.0-alpha-4 and use this opportunity to remove deprecations and modernize Vavr internals while minimizing major breaking changes (timeline: late 2025). I believe that migration from 0.x to 1.0.0 should be as smooth as possible.
  • that means that 1.x would be really close to 0.11.0, but with deprecated APIs trimmed and a couple of backward-incompatible adjustments
  • that means that version/0.x branch would become the main branch
  • 1.0.0 could feature same new implementations of existing collections. Five years ago, I created this issue: Explore reimplementing HashMap as CHAMP (Compressed Hash-Array Mapped Prefix-tree)  #2417. Fast-forward a couple of years, and now we have new implementations done by @wrandelshofer
  • the reason for this is that the existing 1.0.0 stream was an ambitious attempt to make some core changes that were never finalized and I'd rather deal with "why haven't you shipped X?" than "I upgraded to the next major version, and my production broke due to some subtle changes". I think it’s better to keep going with what's battle-tested already
  • I’m leaning towards making a bold move and migrating to Java 21 in 1.0.0 since we need to set an ambitious baseline for the future. Keep in mind that when 1.0.0 will be released, Java 25/26 will be out there
• start crafting a new strategy for “Vavr 2.0.0” - we’re now in a new reality where Java is catching up and “aligning to Scala” is no longer as attractive as it used to be (especially when considering Scala 3 as baseline) (timeline: 3+ years)
  • this could be simply another major version, or even a separate artifact - anything is possible
  • I'm personally romancing the idea of "aligning to Java" instead of "aligning to Scala"

Additionally, I think that pattern matching should be available via a separate library and be kept outside of core vavr - as Java’s switch-case is getting more powerful, it will be natural replacement for Vavr’s pattern matching, but until it happens - we should not kill it immediately.



Short-term goals remain the same: bring back Vavr from the dead, for example: #2906

The above is not set in stone - this is a discussion and not a blog post :)

Happy New Year 🚀

Existing 2.0.0 discussion: https://github.com/orgs/vavr-io/discussions/2866

[He-Pin]

agree with the pattern matching one, as Java 21 is there:)

[diversit]

Thanks for sharing. It looks good to me.
Supporting the thought of moving pattern matching to a separate library.
I hope this will allow changing Vavr types to Java records, where possible, to allow better pattern matching. E.g. to allow pattern matching on an Option like can be done in Scala.