While browsing the code of java.util.logging.Handler, I noticed a theoretical possibility that 'sealed' package-protected instance field be observed as either 'true' or 'false' if a reference to Handler object is obtained via data race.
There is a plain boolean instance field 'sealed' in j.u.l.Handler that is pre-initialized to 'true' in field initializer. Handler sublcass' constructors overwrite this value with 'false' temporarily, then issue some operations, and finally they reset the 'sealed' value back to 'true' before the end of constructor.
If a reference to an instance of Handler subclass is passed to some thread without synchronization via data-race, this thread can see 'true' or 'false' as the possible values of 'sealed' variable.
Here's a possible patch which eliminates the 'sealed' variable and uses doPrivileged() for temporary elevations of privilege for sections of code that need it:
http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/
There is a plain boolean instance field 'sealed' in j.u.l.Handler that is pre-initialized to 'true' in field initializer. Handler sublcass' constructors overwrite this value with 'false' temporarily, then issue some operations, and finally they reset the 'sealed' value back to 'true' before the end of constructor.
If a reference to an instance of Handler subclass is passed to some thread without synchronization via data-race, this thread can see 'true' or 'false' as the possible values of 'sealed' variable.
Here's a possible patch which eliminates the 'sealed' variable and uses doPrivileged() for temporary elevations of privilege for sections of code that need it:
http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.03/