[ 
https://issues.apache.org/jira/browse/LANG-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917678#comment-13917678
 ] 

Sebb commented on LANG-980:
---------------------------

The StringBuilder objects are in fact used by the lexx method to collect the 
text characters, but that could be done before creating the Token object with 
the string contents.

There's another possible simplification - the Tokens are created as a list and 
then converted to an array - however the code could just use the original list. 

Also the list of Tokens needs to be searched to determine if it does (or does 
not) contain various of the duration specifiers.
The lexx method could build a Set of contained types to avoid scanning the 
Token list.

> DurationFormatUtils uses == for comparing objects
> -------------------------------------------------
>
>                 Key: LANG-980
>                 URL: https://issues.apache.org/jira/browse/LANG-980
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.time.*
>            Reporter: Sebb
>            Priority: Minor
>
> As reported on the ML, Findbugs complains that == is being used to compare 
> objects in the class DurationFormatUtils.
> These objects are the strings which define the various durations: "y", "M", 
> "d" etc.  These are final static objects (singletons) so the use of == should 
> be OK but it is not good practice.
> One way to avoid the warnings would be to use an Enum for the singleton 
> objects. For example:
> {code}
> enum Duration { YEAR, MONTH, ... }
>     static final ParseObject y = ParseObject.YEAR;
>     static final ParseObject M = ParseObject.MONTH;
> ...
> {code}
> Note: the package protected fields y, M etc are currently needed for the unit 
> tests.
> The above change would then allow the format() method to use a switch 
> statement which would likely be faster than the if chain it has to use now.
> Eliminating the warnings for == which are currently safe would make it 
> obvious if == was used elsewhere in an unsafe way.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to