Theoretical data race on java.util.logging.Handler.sealed
mandy.chung at oracle.com
Mon Dec 23 04:50:49 UTC 2013
On 12/22/2013 5:23 AM, Peter Levart wrote:
> Hi Mandy,
> On 12/19/2013 10:38 PM, Mandy Chung wrote:
>> On 12/19/13 7:49 AM, Peter Levart wrote:
>>> Hi Mandy, Daniel,
>>> I didn't like the package-protected getters either. So here's
>>> another variant that replaces Handler.configure() method with a
>>> package-protected constructor which is chained from JDK subclasses:
>> Looks good. Thanks for making the change and the new test. It'd be
>> good to close the handlers by the test. The test is running in
>> othervm mode and the Cleaner thread will close the handler when VM
>> exits and the test is fine as it is.
> Well, not really. The Cleaner only closes Handlers that are attached
> to Loggers but the test just instantiates Handlers and doesn't add
> them to any Loggers. It's harmless as it is, othervm will exit
> nevertheless and resources will be freed...
> I tried closing Handlers at the end of test, but that requires
> "control" LoggingPermission and we don't want to run the test with
> "control" permission since we want to check that instantiating
> Handlers (SocketHandler too) doesn't require "control" permission.
Thanks and the test is fine as it is.
> So should anything else be done before pushing this to jdk9/dev ?
Fix looks good and have a regression test. It's good to go and push to
jdk9/dev. No other approval needed.
More information about the core-libs-dev