Hi Peter,
On 12/8/2013 11:19 AM, Peter Levart wrote:
H Mandy,
I created an issue for it nevertheless:
https://bugs.openjdk.java.net/browse/JDK-8029781
You're right, doPrivileged() is a more straight-forward approach than
'sealed' variable. Since this might only be considered for inclusion
in JDK9 when lambdas are already a tried technology, how do you feel
about using them for platform code like logging? As far as I know
(just checked), lambda meta-factory is not using any j.u.logging, so
there is no danger of initialization loops or similar:
http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/
Sorry for the delay to get to this.
Alan is right that java.lang.invoke.ProxyClassesDumper does use
PlatformLogger which will forward calls to j.u.logging if
-Djava.util.logging.config.file is set or java.util.logging has been
initialized (via other j.u.logging call). It means that it may lead to
recursive initialization. Also the current PlatformLogger
implementation formats the message in the same way as j.u.logging that
may load locale providers and other classes. I am afraid there are
issues to tease out and resolve.
The overloads the doPrivileged method makes it cumbersome to use lambda
that causes you to workaround it by adding a new PrivilegedVoidAction
interface which is clever. So I think it isn't too bad for this patch
to use anonymous inner class and have the doPrivileged call in the
constructor.
Mandy
