Make Java17+ version and transform some classes to records (Tuples, Either, Try and Validation)

[Vyacheslav-Lapin]

Many Java projects statistically already use Java 17+ version (actually it is required for supported versions of the most popular Java framework, Spring), so maybe it's time for VAVr to follow this trend too?

Java 16+ has JEP 395 with record which is very interesting for FP concepts:

1. it is immutable,
2. it has support for Pattern Matching (JEP 440 - Record Patterns) in Java 21+.

So I think it would be great to declare Java 17 support as the minimum possible version and convert some classes to records - especially Tuples, Either, Try and Validation - so that Java 21 users can use Pattern Matching with them.

[EarthCitizen]

This is duplicate/overlap with #2764.

[pertl]

+1 on that ... but please first release 1.0.0 then release a 2.x with java 17+ requirements

[EarthCitizen]

@pertl I think we just need to figure out who will do the release :-)

[bowbahdoe]

I don't think this is either a good idea to do now or a good idea in general.

Consider Option.

• The top level None and Some classes are deprecated already. Maybe that should be undone and Option made sealed - idk.
• Currently None lacks a public constructor. Making it a record will add one.
• Both None and Some are Serializable. This means that it is wholly possible someone serialized one to a database somewhere and might want to read it back in later. I don't think that there is any way to change them to records without breaking old serial forms.
• Option is currently an abstract class, not an interface. We cannot have records extend from an abstract class or change an abstract class to an interface without very pointless binary compatibility issues.
• If we wait long enough we can just add regular pattern methods to Option.

switch (opt) {
    case Option.none() -> {}
    case Option.some(var x) -> {}
}

And that will just be better than making things records since we don't need to compromise any backwards compatibility for it.

[bowbahdoe]

To be clear, I am in favor of upping the baseline version of Java required. Thats whatever. It needs to happen eventually to take advantage of patterns anyways. Might as well align on the "tip and tail" thing brian goetz brings up.

[EarthCitizen]

@bowbahdoe The current discussions are going more in the direction of releasing current code as 1.0.0, then circling back to this type of advancement ins 2.0.0.

[bowbahdoe]

I vehemently disagree with doing any sort of 2.0 that doesn't also change G:A and package + module names so both can coexist. (while i'm dumping opinions on direction)

[pivovarit]

Personally, I'm leaning towards releasing 0.11.0 first: current code + bugfixes + module.info(via a multi-release jar) + package.info.

I synced with Daniel, and it seems like there's consensus that the current courageous 1.0.0 attempts went nowhere and that a reset is needed. I need to do some digging on my own to understand how severe the problem is.

However, if that's the indeed the case, then 1.0.0 could be 0.11.0 with a JDK17-friendly facelift