[
https://issues.apache.org/jira/browse/LUCENE-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725456#action_12725456
]
Shai Erera commented on LUCENE-1653:
------------------------------------
In 3.0 when we move to Java 5, we can make Resolution an enum, and then use a
switch statement on passed in Resolution. But performance-wise I don't think it
would make such a big difference, as we're already comparing instances, which
should be relatively fast.
How will moving the logic of timeToString, stringToDate and round to Resolution
make the code tighter? Resolution would still need to check its instance type
in order to execute the right code. Unless we subclass Resolution internally
and have each subclass implement just the code section of these 3, that it
needs?
> Change DateTools to not create a Calendar in every call to dateToString or
> timeToString
> ---------------------------------------------------------------------------------------
>
> Key: LUCENE-1653
> URL: https://issues.apache.org/jira/browse/LUCENE-1653
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Other
> Reporter: Shai Erera
> Assignee: Mark Miller
> Priority: Minor
> Fix For: 2.9
>
> Attachments: LUCENE-1653.patch, LUCENE-1653.patch
>
>
> DateTools creates a Calendar instance on every call to dateToString and
> timeToString. Specifically:
> # timeToString calls Calendar.getInstance on every call.
> # dateToString calls timeToString(date.getTime()), which then instantiates a
> new Date(). I think we should change the order of the calls, or not have each
> call the other.
> # round(), which is called from timeToString (after creating a Calendar
> instance) creates another (!) Calendar instance ...
> Seems that if we synchronize the methods and create the Calendar instance
> once (static), it should solve it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
