Designing for value types

[Brian Goetz]

Since Java 8, several classes (Optional, LocalDateTime, etc) have been 
tagged as _valued based_: 
https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html

This was our stake in the ground that these classes might become 
candidates for migrating to values.  These guidelines are a pretty good 
start, but have some known holes.  Plus, its a generally good way to 
model many things.

The biggest known gap is nullability.  Value types can't be null; not 
only can reference types be null, but that's actually their default 
value!  You can see the problem.  The definition of value-based says 
nothing about null, because, well, it seems kind of silly to say 
"value-based types shouldn't be null" when that's exactly the default 
value the JVM places in them.

If you program with value-based classes now, and have good hygiene about 
nulls (don't leave fields uninitialized, don't store nulls in them) -- 
which a lot of code does -- migrating to values should be relatively 
painless.  We're working on lint warnings in javac to flag uses of 
value-based classes in ways that won't migrate well to values, which 
will help further.

If you're in a position to recompile all clients when you switch from 
value-based classes to value types (a common situation for simple domain 
classes), and you've kept your code clean, the migration should be 
pretty smooth.  The migration for existing types like Optional, which is 
used (and misused) from lots of existing code, is going to be a longer 
and rockier road.




On 6/6/2018 9:51 AM, David Lloyd wrote:
> There are various classes in the JDK which follow certain practices,
> seemingly in the hopes of being "value-ready".  These practices
> include things like:
>
> • No public constructors (use static factory methods instead)
> • Make the type `final`
> • No inheritance (probably? prefer composition I guess?)
> • No mutable state
>
> Understanding that it is still "early days" and that things can still
> change dramatically, is it realistic to expect that classes designed
> to the above rules can more or less seamlessly transition to value
> classes in a future JDK?  Is there a definitive list of additional
> things an API can do to anticipate value types, minimizing the
> likelihood of transition problems, or is it categorically too soon to
> tell?
>