Review request for 6810254
David Holmes - Sun Microsystems
David.Holmes at Sun.COM
Thu Mar 5 12:18:55 UTC 2009
Isn't this kind of change risky? With static initialization you know
that once the VM gets up and running then everything is in place. But
with lazy-initialization (and using reflection no less!) there's a
danger that when you try to initialize you're more likely to fail due to
lack of memory or resources. I can't quite tell exactly when these
setSharedSecret methods will be called.
BTW I think the comments copied into
src/share/classes/java/io/DeleteOnExitHook.java need to be reviewed -
they made sense when the code was java.io.File, but not now :)
Mandy Chung said the following on 03/05/09 17:01:
> 6810254: Lazily instantiate the shared secret access objects
> Webrev at:
> sun.misc.Java*Access objects are created at initialization time.
> However, they are not always needed. They can be instantiated lazily
> when needed. The fix is to add a static setSharedSecret() method to be
> called by sun.misc.SharedSecrets via reflection when the shared secret
> access object is requested.
More information about the core-libs-dev