[wpiutil] Add Java algebraic data types

[SamCarlberg]

We currently use Java's Optional type to represent optional values, such as alliance station or color. This can still lead to errors in user code, however, since there's no guardrails to prevent users from calling get() without first checking for isPresent(). Adding ADTs for optional values would allow us to leverage the type system to put such guardrails in place.

This requires Java 21 for its pattern matching support. It would still be possible on Java 17 with its enhanced instanceof and sealed types, but the checks are clunky. Tagging this for 2027 for MRC and Java 21+ support

// Rust naming for sake of example
sealed interface Option<T> permits Some, None {
  record Some<T>(T value) implements Option<T> {}
  record None<T>() implements Option<T> {}
}

Option<Alliance> getAlliance() { ... }

// Java 21+
boolean shouldFlipPaths = getAlliance() instanceof Some(Alliance color) && color == Alliance.kRed;

// Java < 21
boolean shouldFlipPaths = false;
if (getAlliance() instanceof Some<Alliance> some) {
  shouldFlipPaths = some.value() == Alliance.kRed;
}

Types like Rust's Result probably shouldn't be added. Java already functionally has that with exceptions, which also force users to either handle the error results or let their program crash; a Result type would allow users to just ignore errors, which would be a regression

[narmstro2020]

I didn't know Java 21 brought in so many wonderful ADT features.

This will be useful almost everywhere in the codebase.

For instance the units library. 👍

[SamCarlberg]

@narmstro2020 I hadn't considered how the units library would be affected. Can you give some examples of how you think it'd be used?

[narmstro2020]

You could reduce the amount of instanceof's that currently exist in the api. With pattern matching. That's the first thing that came to mind.

The entire API is just loaded with types. It really just depends on how well ADTs and pattern matching play well with Java generics or if an alternative can be found.

[SamCarlberg]

Well, measures are technically already product types; they'll just formally become so when we can transition them to records in 2027. I don't see how pattern matching would be useful for them, since you typically use the direct measure types when possible (eg Distance instead of Measure<DistanceUnit>), and can just call API methods directly without deconstruction

[narmstro2020]

Whats preventing records from being used now. I thought they were a Java 14 feature?

[SamCarlberg]

Whats preventing records from being used now

Immutability constraints imposed by the roboRIO. 2027 will have just a single record for measure objects, instead of an interface with an immutable and a mutable implementation.

[neebah]

The thought was mostly a potential. I was watching a tutorial on ADT's in Java. Remembered your post and had a low level epiphany.

It may be for nought. It might be useful it might not. Wanted to share with you either way.

[narmstro2020]

Sorry that above comment was from me on a different github account. Oopsy

I'm wondering if project Valhalla with its value based types will benefit the Units API as well.