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

[Peter Levart]

On 12/18/2013 12:05 PM, Daniel Fuchs wrote:
>> But then we have another problem with doPrivileged approach, since it is
>> even more restrictive than 'sealed' field approach. Currently the
>> Handler's subclass that overrides a setter and calls super, works:
>>
>>
>> @Override
>> public void setOutputStream(OutputStream out) {
>>      super.setOutputStream(out);
>> }
>>
>>
>> With doPrivileged wrapping setOutputStream in the superclass
>> constructor, it will throw SecurityException if the subclass protection
>> domain does not have the "control" permission...
>>
>> Can this break custom handlers in some environment?
>
> Good question. It may yes - but on the other hand, a subclass of
> handler that override such methods and call the super.method would
> *need* to have the control permission too - wouldn't it?
>
> Otherwise calling these methods when sealed is back to true would
> always fail...

There might be no need to call the overridden setters after the Handler 
instance is constructed. Apart from "setLevel", Handler setters are only 
called by Handlers themselves in construction phase and by user code... 
If user code doesn't need to call the overridden setters after handlers 
are constructed, user code doesn't need the "control" permission.

But than again, user would *need* to have "control" permission anyway to 
make use of a newly constructed Handler. If all she can do is 
instantiate new Handler instances and not add them to Loggers, what good 
does it make?

Regards, Peter

>
> best regards,
>
> -- daniel