Designing for value types

[Tagir Valeev]

Hello!

Assuming that LocalDateTime would be a value type, which default value
should it have?

With best regards,
Tagir Valeev.

ср, 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?
> >
>
>