System.currentTimeMillis check in System class during startup.

[jon.vanalten at redhat.com]

Hello all,

We've been having a discussion on the downstream IcedTea bugzilla about a potential jdk bug, and it seems prudent to bring it up here.  Link:

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=394

Please ignore discussion there RE 32-bit *nix time overflow in 2038; this is a glibc issue that Java cannot resolve.  What I am more concerned about is the complete incompatibility with any negative currentTimeMillis() return value.

TL/DR: System class does a (currentTimeMillis() > 0) check as part of method that only exists to avoid inlining of the initial null assignment of the in/out/err streams.  So, if system time is before January 1, 1970, java will not start.  The bug reporter has given several potential use cases where this could occur (summary in comment 14 of bug report).

In my opinion, this is a bug.  The comment preceding the methods in which this check occurs indicate that it is only to prevent inlining; Java should not, IMO, care whether the system clock is set to 2367CE, 2010, or 42BCE.  Provided, of course, that the date falls within the 64 bit signed long value that the currentTimeMillis() method returns.  In other words, I think that Java should not be concerned with whether the system clock is in sync with real world time.

I've tried changing the check to (currentTimeMillis() >= Long.MIN_VALUE), to maintain the prevention of inlining while allowing startup to proceed.  Patch attached.  This seems to work, in that when system clock is before 1970 a program can actually start up.  There does not seem to be unwanted side effects when running a few simple programs, although I have not done any real regression testing.

Is this something that others think should be fixed in the JDK?  Or are Java users ultimately required to ensure that their system clock is set accurately (and they are not time travelling hehe)?

Related: I've been looking through other use of currentTimeMillis() throughout the JDK, and I've found a few other places where there seem to be assumptions made about the approximate expected return value.  If others are of the same opinion that Java should be agnostic about what a "sensible" system time should be, then I'll summarize my findings in a future post.

Your thoughts are appreciated.

cheers,

jon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pre1970-system-init.patch
Type: text/x-patch
Size: 894 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20100628/02717422/pre1970-system-init.patch>