[Bug 394] Y2038 time overflow/pre Epoch bug : java.lang.ExceptionInInitializerError on systems with uninitialized clock

[bugzilla-daemon at icedtea.classpath.org]

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





------- Comment #5 from xerxes at zafena.se  2010-06-22 09:46 -------
(In reply to comment #4)
> I don't believe this is really a JDK bug.

I think it still are a JDK bug since it are impossible to write any user java
application that can workaround this bug. This are because the exception happen
before my own java programs main are executed and thus are uncatchable from the
users java application. Please correct me if i am wrong here.

> The NPE is thrown during initialization after a failed check that
> System.currentTimeMillis() > 0.  Until time travel is invented, this is a sane
> check.

You dont have to invent time travel in order to hit this bug, I have hit this
bug several times during 2009-2010 by simply trying to boot up any java
application on newly manufactured embedded hardware where the systemclock never
have been set to a sane value.

Why should we not allow java applications to continue to run for people who
manage to perform time travel jumps? 
It are perfectly possible that this bug makes any java driven time machine
malfunction after the jump and prevents it to actually return back :)

there also exists systems suitable for running java that are not equipped with
a clock battery.

> Even if initialization was allowed to proceed in this case, there are many
> classes that depend on sane return values from currentTimeMillis().
> 

whats wrong with negative millis numbers? java doc only specify that
currentTimeMillis() will return a long.

If initialization would be allowed to continue then i would actually be able to
create a application written in java that could detect and update the clock.


-- 
Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.