Sealed Class Support

[GeluOltean]

Hey everyone!

Considering JDK17 is a LTS version and the sealed class feature being production ready with its release, are there any plans regarding using this feature for defining parametric algebraic data types? Being able to use switch expressions to pattern match would be great for developer experience.

Not sure if using JDK17 would be out of scope for now or not, hence the issue.

[danieldietrich]

Hi! Thank you for asking - yes, indeed, I plan to migrate to JDK17.

[GeluOltean]

I'd love to help out with this!

[danieldietrich]

Thank you! Please outline your idea here first, e.g.

• which Vavr types do we want to cover (Either, Option, Try and Validation but not Future, Promise and collections?)
• which actions are needed to change the codebase (use interfaces instead of abstract classes? make static inner classes public and move them into the package?)
• depend on Java 17
• any other things?

[GeluOltean]

Will do! Taking a closer look now, was waiting to clarify whether JDK17 is desired/planned.

Indeed, I was thinking about changes for Either, Option, Try and Validation. Will come back soon with a more detailed outline in a bit.

[danieldietrich]

Great to hear! Thank you!

[bduisenov]

Hey @GeluOltean, do you have any updates on this?

[GeluOltean]

Hey @bduisenov; got a bit overwhelmed by a previous project and did not manage to make much progress on this. It should be possible, but I do not have an idea yet of how extensive the changes would be.

[eslep]

@bduisenov @danieldietrich I'd be happy to take a crack at this, as I'm quite happy about Java introducing Pattern Matching and am eager for this.

The plan would be quite simple I think.

Candidates:

• Either, Option, and Try definitely would get the change. Validation as well, if that is still being kept?
• Future/Promise I can still seal so they are closed for extension. They won't be relevant to Pattern Matching since there is only one sensible implementation, but I personally don't see a need to extend them or leave them open to extension either. Would defer to your thoughts/opinion/guidance on this, however.
• Collections like List, Stream, Tree I would also be happy to include, though personally I won't find them as useful until Java would fully implement general deconstruction
• Nothing else, all other classes are final

Approach:

• I would plan to keep the abstract classes. In 0.10.4 which I am used to working with, these are still interfaces, so I assume you had reasoning behind the move to abstract classes and I see no reason to roll that back.
• All of these already have static final inner classes for the implementations, and I would keep it that way.
  • Personally, I would probably normally implement a sum type like this, with inner classes & same file
  • 'Same file' matches also the way that Scala does sealed
  • This makes the hierarchy/grouping clear and prevents conflicts between List.Cons/Stream.Cons and Stream.Empty/Tree.Empty
• The top-level abstract classes would simply become public abstract sealed, and the concrete classes are already public static final.
  • Stream is a special case with slightly different hierarchy, since Stream.Cons is abstract and implemented by two private static final inner classes. So I would seal Stream.Cons as well, while keeping the implementations private (I would say nobody needs to know what kind of Cons it is, no?)
• Update to Java 17
  • Bump version in build.gradle
  • Change Java version in Travis CI config, drop all previous versions since this is a breaking change
  • Update documentation referencing things like 'Vavr is for Java 8+'

The only real issue I see here (from my understanding) is the fact that #2346 will be blocking this due to the Java version update.