commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (NET-367) ntp.TimeStamp uses incorrect lazy initialisation of static fields simpleFormatter and utcFormatter
Date Tue, 22 Mar 2011 22:40:06 GMT

     [ https://issues.apache.org/jira/browse/NET-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sebb resolved NET-367.
----------------------

       Resolution: Fixed
    Fix Version/s: 3.0

Made SDF objects instance variables

> ntp.TimeStamp uses incorrect lazy initialisation of static fields simpleFormatter and
utcFormatter
> --------------------------------------------------------------------------------------------------
>
>                 Key: NET-367
>                 URL: https://issues.apache.org/jira/browse/NET-367
>             Project: Commons Net
>          Issue Type: Bug
>            Reporter: Sebb
>             Fix For: 3.0
>
>
> Findbugs reports that ntp.TimeStamp uses incorrect lazy initialisation of the static
fields simpleFormatter and utcFormatter.
> This is because the static fields are written and read without synchronisation. One proposed
solution is to make the static fields volatile.
> The fields are SoftReferences containing SimpleDateFormat instances. SimpleDateFormat
(SDF) is not thread-safe, so when it is used, the code has to synchronize on the instance.
> Are the SoftReferences necessary? Does it really matter if the field cannot be garbage-collected?
> If not, an Init on Demand Holder (IODH) be safer, and would avoid creating the instance
if it was not needed.
> Also, is it necessary to use static fields to hold the SimpleDateFormat instances, given
that this requires the synchronisation when using the methods toUTCString/toDateString?
> The other mutable classes in the package are not thread-safe (mutable fields are not
volatile or synch) so overall thread-safety for the package would not be compromised by using
instance fields and removing the SDF synchronisation and SoftReference.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message