Hi,
I read the code that the assignment is of the value returned by
"toFormatter()".
In this "fluent" style each of the intermediates is an instance on which
the next method is executed.
The assignment is not done until after 'toFormatter()' completes.
Roger
On 7/12/2013 9:37 AM, Nils Kilde
On Fri, Jul 12, 2013 at 8:05 AM, roger riggs wrote:
> I don't see a functional issue with this;
>
You need to study the Java memory model then.
> The DateTimeFormatter created by each thread will have exactly the same
> behavior and semantics.
> The caller gets an instance that preforms as req
I don't see a functional issue with this;
The DateTimeFormatter created by each thread will have exactly the same
behavior and semantics.
The caller gets an instance that preforms as required.
dt is just a cache to improve performance.
The only condition at risk is the two calls to dateTime() do
You may be right, although neither volatile nor synchronized are appealing here.
Please raise an issue on GitHub
Stephen
On 12 July 2013 10:19, Lin Wang wrote:
> The javadoc of ISODateTimeFormat class says it's thread-safe and immutable.
> The static fields are lazily initialized. However it seem
The javadoc of ISODateTimeFormat class says it's thread-safe and immutable.
The static fields are lazily initialized. However it seems it's not done in
a thread-safe manner.
For example, dt is lazily initialized in
public static DateTimeFormatter dateTime() {
if (dt == null) {
