JDK-6912866 : (date) java.util.Date.before / after may be expensive
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 6u17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2009-12-23
  • Updated: 2011-02-16
  • Resolved: 2010-02-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u21Fixed 7 b84Fixed
Related Reports
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_17"

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Date's before and after methods call getMillisOf(), which will clone the cdate variable if not-null. NB: cdate is not null after a simple call to toString(), for instance for logging purposes.

On the other hand getTime() does not incurr the cloning penalty. So rewriting
a.before(b) to a.getTime() < b.getTime() uses less memory, which is sad. The semantically string before/after should not be more expensive than a verbose getTime() construct.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Have an application relying a lot on before() and after()
2. Perform logging that calls toString() on the date instances

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
before() and after() should not perform any object allocation.
ACTUAL -
before() and after() clone the internal BaseCalendar.Date.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.Date;


public class BeforeTest {
    public static void main(String[] args) {
        int n = 100000;
        Runtime rt = Runtime.getRuntime();
        Date a = new Date();
        a.toString();
        Date b = new Date();
        b.toString();
        
        long mem1 = rt.totalMemory() - rt.freeMemory();
        for (int i=0; i<n; i++) {
            if (a.getTime() < b.getTime()) continue;
        }
        long mem2 = rt.totalMemory() - rt.freeMemory();
        System.out.println("with getTime(): "+ (mem2 - mem1));
        
        
        mem1 = rt.totalMemory() - rt.freeMemory();
        for (int i=0; i<n; i++) {
            if (a.before(b)) continue;
        }
        mem2 = rt.totalMemory() - rt.freeMemory();
        System.gc();
        System.out.println("with before(): "+ (mem2 - mem1));
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use getTime() instead of before() or after().

Comments
EVALUATION The methods should avoid cloning when the cdate is in sync with `fasttime'.
18-01-2010