Java Reference
In-Depth Information
return
LocalDate
.
from
(
temporal
)
.
withMonth
(
Month
.
OCTOBER
.
getValue
())
.
with
(
TemporalAdjusters
.
firstDayOfMonth
());
default
:
return
null
;
// Will never happen
}
}
}
Let's look at an example of how to use an adjuster:
LocalDate
now
=
LocalDate
.
now
();
Temporal
fdoq
=
now
.
with
(
new
FirstDayOfQuarter
());
System
.
out
.
println
(
fdoq
);
The key here is the
with()
method, and the code should be read as taking in one
Temporal
object and returning another object that has been modified. This is com‐
pletely usual for APIs that work with immutable objects.
Legacy Date and Time
Unfortunately, many applications are not yet converted to use the superior date and
time libraries that ship with Java 8. So, for completeness, we briefly mention the leg‐
acy date and time support (which is based on
java.util.Date
).
The legacy date and time classes, especially
java.util.Date
, should
not
be used in Java 8
environments.
In older versions of Java,
java.time
is not available. Instead, programmers rely
upon the legacy and rudimentary support provided by
java.util.Date
. Histori‐
cally, this was the only way to represent timestamps, and although named
Date
this
class actually consisted of both a date and a time component—and this led to a lot
of confusion for many programmers.
There are many problems with the legacy support provided by
Date
, for example:
• The
Date
class is incorrectly factored. It doesn't actually refer to a date, and
instead is more like a timestamp. It turns out that we need different representa‐
tions for a date, versus a date and time, versus an instantaneous timestamp.
•
Date
is mutable. We can obtain a reference to a date, and then change when it
refers to.
• The
Date
class doesn't actually accept ISO-8601, the universal ISO date stan‐
dard, as being as valid date.
•
Date
has a very large number of deprecated methods.