Designing for value types

[David Lloyd]

On Wed, Jun 6, 2018 at 9:06 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 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.

TBH this never was an expectation of mine... when it came up on the
list my reaction was mostly "huh??".  The reason is because even after
all these years I still think of Java like C: to me, a class is a
struct, and a reference is a pointer (sort of) to that struct, and
pointers can be null, and structs can't; I imagined using value types
(more or less) where I might have used a (direct) struct in C.  The
lack of mutability was a bigger curveball TBH, though a manageable one
(at least, so it appears thus far).  I can say with certainly that
value types would be useful (to me anyway) with or without
nullability.

> 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.

Do you mean to imply that it is likely that reference fields within
value types will not allow null?

> 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.

Great, that seems like the best one can hope for at present.

-- 
- DML