System.currentTimeMillis check in System class during startup.
Martin Buchholz
martinrb at google.com
Tue Jun 29 01:49:56 UTC 2010
It's not at all clear that one cannot solve the y2038 problem on
systems with a 32-bit time_t.
That's what Michael Schwern is trying to do here:
http://code.google.com/p/y2038/
His code is available.
The JDK should find some other anti-inlining technique.
The code should be agnostic about the current time, as suggested.
Martin
On Mon, Jun 28, 2010 at 07:14, <jon.vanalten at redhat.com> wrote:
> 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
More information about the core-libs-dev
mailing list