Designing for value types

[Brian Goetz]

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


That's certainly our position, but not everyone feels this way. People 
do things like

     LocalDateTime date = null;   // means unknown, obviously

or have maps

     Map<Foo, Optional<Bar>> m  = ...
     m.put(foo, null)

I don't write code like this, and you probably don't either, but people 
do, and to be fair to them, no one told them not to.  So there will be a 
migration challenge.
>
>> 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?

No, there's no change there.  It's values that can't be null (or 
synchronized on, or a few other things.)