Designing for value types

[Remi Forax]

----- Mail original -----
> De: "Tagir Valeev" <amaembo at gmail.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "amber-dev" <amber-dev at openjdk.java.net>
> Envoyé: Mercredi 6 Juin 2018 16:57:03
> Objet: Re: Designing for value types

> Hello!
> 
> Assuming that LocalDateTime would be a value type, which default value
> should it have?
> 
> With best regards,
> Tagir Valeev.

The default value for the VM or for Java ?
For the VM, all fields are initialized to their default value, yes, the definition is recursive, but you can not have cycle with value types.
For Java, you have to call one of the factory method, so it depends the factory method you call.

So in Java, the default of a value type is more like a class than like an int.

For arrays, all elements are initialized to the VM default value, so every fields is 0, null, 0.0, false, etc

Rémi

> 
> ср, 6 июня 2018 г., 21:07 Brian Goetz <brian.goetz at oracle.com>:
> 
>> 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?
>> >
>>