On 28/02/2012 03:57, Mike Duigou wrote:
Hello all;
This issue is a patch for review that I have split out of a larger issue I'll
be submitting later.
WEBREV @ http://cr.openjdk.java.net/~mduigou/7149320/0/webrev/
sun.misc.VM.booted() is currently called before setJavaLangAccess(). For code
which uses the JavaLangAccess shared secrets it's convenient to be able to
check whether the secrets are initialized without having to call
sun.misc.SharedSecrets.getJavaLangAccess() every time the secrets are used and
checking for null. In particular with the static inner class holder idiom it
would be desirable to do :
static class Holder {
final sun.misc.JavaLangAccess ACCESS =
sun.misc.SharedSecrets.getJavaLangAccess();
}
...
if(sun.misc.VM.isBooted()&& Holder.ACCESS...
In my research on this issue I was unable to determine why sun.misc.VM.booted()
isn't the currently the last activity in System.initSystemClass(). Neither of
the two tasks which currently follow it depend upon booted state in any way
that I could determine. I am tempted, thinking about it, to add a comment to
System.initSystemClass before the call to sun.misc.VM.booted() asking future
maintainers to leave boot() as the last activity or explain why not.
I have done JTReg runs on linux x86, linux x64 and Solaris 64 which
incorporated this change without any problems encountered. It's rather
difficult to write a unit test for this issue as it requires a class that is
initialized after java.lang.System but before
java.lang.System.initSystemClass() and uses JavaLangAccess.
Thanks,
Mike
We do need to take great care in System.initSystemClass. I think the
safest thing would be to just move setJavaLangAccess to before the call
to VM.booted(). At one point the access to java.lang was setup
immediately after the system properties were initialized so we've been
there before.
-Alan
