Change in properties for logging: deliberate?

Jeremy Manson jeremymanson at
Fri Nov 10 20:48:58 UTC 2017


Thanks for taking a look at this.  I'd like to disagree with the reasoning

First, it isn't just JDKs 7 and 8 - the behavior is the same all the way
back to JDK 1.4, when the java.util.logging API was introduced.  So changes
affect 15 years' worth of logging configuration files.  For example, there
are no fewer than 350 instances of this pattern in our codebase.  Imagine
multiplying that across the entire world - everyone who is doing this has
to change their configuration.  That's a pretty big cost to introduce on
the developer community.

This is worse on legacy systems, because the handlers property was broken
for a long time, and people basically had to use .handlers:

Second, it is inconsistent for ".level" to work for level for the root
logger, and ".handlers" not to work for handlers for the root logger.  The
empty string represents the root logger, and having it only represent the
root logger sometimes is (to me) counterintuitive.  Without checking, my
suspicion is that .level behaves the same way as .handlers (that is, it is
only loaded once).  If we can live with the inconsistency there, we can
live with it here.  You can even document that that is the difference.


On Fri, Nov 10, 2017 at 8:04 AM, Daniel Fuchs <daniel.fuchs at>

> Hi Jason,
> I have done a few tests with JDK 8 & 7.
> I have created custom handlers and added some
> debug traces in their constructors and debug methods.
> Then I have added these two lines to my
> handlers = custom.Handler
> .handlers = custom.DotHandler
> What I see is this:
> - the first time the configuration is read, two handlers
>   are added to the root logger:
>   - an instance of DotHandler (first), then an instance
>     of Handler (second).
> Then if you call LogManager.readConfiguration() again,
> both handlers are closed, and this time only one
> instance of Handler is added to the root logger.
> No instance of DotHandler is added.
> From now on the property is ignored.
> This is because the root logger is a special beast:
> it will not be removed (like all other loggers) when
> LogManager.readConfiguration() is called.
> And as it happens, handlers are added to loggers
> when the loggers are added to the LogManager.
> As it happens, the ".handlers" property is only parsed
> and read when the root logger is added to the LogManager,
> and thus only once.
> The "handlers" property on the other hand is parsed
> every time LogManager.readConfiguration() is called.
> Given that, I suspect we should deprecate the use of
> ".handlers" for the root logger, as it appears that
> it has never worked properly. I could work on a patch
> for 10 (possibly backport it to 9 update) to preserve
> the strange behavior of 7 & 8, but is it worth it?
> What are your thoughts?
> best regards,
> -- daniel
> On 09/11/2017 19:50, Jason Mehrens wrote:
>> Daniel,
>> I would assume you would fix since it is advertised as a feature over
>> here:
>> changes.html
>> If it helps, I've dug up a lot of the history on this over here a while
>> back:
>> logging-logging-properties-file-whats-the-difference-between-h
>> I've updated that to include the links to this new issue.  Now that I've
>> linked this message thread to that message thread that should crash the
>> internet. :)
>> Jason
>> ________________________________________
>> From: core-libs-dev <core-libs-dev-bounces at> on behalf
>> of Daniel Fuchs <daniel.fuchs at>
>> Sent: Thursday, November 9, 2017 1:29 PM
>> To: mandy chung
>> Cc: core-libs-dev at
>> Subject: Re: Change in properties for logging: deliberate?
>> On 09/11/2017 19:16, mandy chung wrote:
>>> Daniel - we should add this known issue in the release note and document
>>> the workaround.
>> Hi Mandy,
>> Right, it either need to be fixed, or documented in the release
>> notes. Let me first have a look at the issue though.
>> best regards,
>> -- daniel

More information about the core-libs-dev mailing list