Theoretical data race on java.util.logging.Handler.sealed

[Mandy Chung]

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