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
diff -U 3 openjdk/jdk/src/share/classes/java/lang/System.java.orig openjdk/jdk/src/share/classes/java/lang/System.java
--- openjdk/jdk/src/share/classes/java/lang/System.java.orig 2010-06-22 15:37:30.675020377 -0400
+++ openjdk/jdk/src/share/classes/java/lang/System.java 2010-06-22 15:38:59.978971506 -0400
@@ -1099,14 +1099,14 @@
* by initializeSystemClass().
*/
private static InputStream nullInputStream() throws NullPointerException {
- if (currentTimeMillis() > 0) {
+ if (currentTimeMillis() >= Long.MIN_VALUE) {
return null;
}
throw new NullPointerException();
}
private static PrintStream nullPrintStream() throws NullPointerException {
- if (currentTimeMillis() > 0) {
+ if (currentTimeMillis() >= Long.MIN_VALUE) {
return null;
}
throw new NullPointerException();
