RFR (L): 8046148: JEP 158 Unified JVM Logging
kirk.pepperdine at gmail.com
Mon Sep 14 16:37:43 UTC 2015
In my opinion, excessive spaces don’t enhance readability and and generally make parsing more difficult.
> On Sep 14, 2015, at 3:18 PM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
> On 2015-09-11 15:51, Coleen Phillimore wrote:
>> I'm not a big fan of having these blanks in the logging lines. I don't think making the line length longer is going to be helpful and what people are looking for is the message at the end, not which tag and level they used. I think they look kind of strange.
> While it might look a bit weird, I think it can help readers to quickly find the start of the actual log message. Maybe we could leave it as it is for now, deferring the decision if we want the padding or not until we have some real logs to look at. If we find the padding inconvenient at that point we can just remove it in a follow-up RFE.
>> On 9/11/15 9:40 AM, Marcus Larsson wrote:
>>> Yes, decorators are padded to avoid jagged logs and help readability. Since the levels are known beforehand, a fixed padding is used for that decorator. For other decorators such as tags or timestamps, the padding will grow to the size of the longest (so far) seen decoration. This means the decorator prefix length will either stay the same or increase, but never decrease. After a while it should stabilize around some fitting length and not grow significantly.
>>> For example:
>>> [0.655s][debug ][safepoint] Safepoint synchronization initiated. (20)
>>> [0.656s][debug ][safepoint, some_other_tag] Safepoint synchronization initiated. (20)
>>> [0.657s][debug ][safepoint, ] Safepoint synchronization initiated. (20)
>>> [10.657s][debug ][safepoint, ] Safepoint synchronization initiated. (20) \
More information about the hotspot-dev