[5790] in Release_7.7_team
punting JDK 1.6
daemon@ATHENA.MIT.EDU (Robert A Basch)
Wed Jun 13 18:14:25 2007
Message-Id: <200706132213.l5DMDgH5005932@abulia.mit.edu>
To: release-team@MIT.EDU
Date: Wed, 13 Jun 2007 18:13:42 -0400
From: Robert A Basch <rbasch@MIT.EDU>
X-Spam-Flag: NO
X-Spam-Score: 0.00
I encountered a problem in testing JDK 1.6 on Solaris, which leads me
to think we should not update to 1.6 at this time. The problem seems
to occur the first time an applet is executed in a Firefox session
when there is a $HOME/.java directory which has been previously
initialized by Java 6, where $HOME is in AFS. In this scenario,
the Java VM (and thus Firefox itself) hangs for several minutes,
until finally the applet is executed. From running truss on the
process, it appears that a VM thread trying to initialize things
from the .java directory, which tries to mkdir() all of the cache
directories in $HOME/.java/deployment/cache/6.0 (which already
exist), is getting preempted, and then doesn't resume for 3 seconds,
after which each subsequent mkdir() is followed by another delay.
I have not seen the problem with JDK 1.6 on Linux, or with using
a local .java directory, or when the .java directory does not yet
exist.
So, rather than spending any more time on this, I propose we drop
the plan to update to JDK 1.6 in the next release, on both platforms.
Instead, we should update JDK 1.5 to the latest version, update 12.
I have already installed the JDK 1.6 packages in the dev cell r/w OS
volume, and plan to leave them there, as they did not replace anything
from the 1.5 packages. But I will undo the changes I made in the r/w
install volume which would add them to the release, in favor of the
1.5 update. (We could still install the 1.6 packages and leave 1.5
as the default, but that would be inconsistent with Linux, unless
we change our trigger code which makes the latest version the
default; users who want Java 1.6 can stil access it via the java
locker).
Please speak up soon if you object to this new plan.
Bob
