Designing for value types
brian.goetz at oracle.com
Wed Jun 6 15:29:45 UTC 2018
> 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
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 = ...
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
>> 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.)
More information about the amber-dev