[ https://issues.apache.org/jira/browse/LUCENE-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725447#action_12725447 ]
David Smiley commented on LUCENE-1653: -------------------------------------- I'm looking through DateTools now and can't help but want to clean it up some. One thing I see that is odd is the use of a Calendar in timeToString(long,resolution). The first two lines look like this right now: {code} calInstance.setTimeInMillis(round(time, resolution)); Date date = calInstance.getTime(); {code} Instead, it can simply be: {code} Date date = new Date(round(time, resolution)); {code}. Secondly... I think a good deal of logic can be cleaned up in the other methods instead of a bunch of if-else statements that is a bad code smell. Most of the logic of 3 of those methods could be put into Resolution and be made tighter. > 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