Need comments on JEP-158: Unified JVM Logging

[Fredrik Arvidsson]

Hi Dmitry, thanks for the feedback.

I will comment in-line below.

On 2014-05-16 15:40, Dmitry Samersoff wrote:
> Fredrik,
>
> 1. I'm not sure we have to provide user-configurable decoration.
>
>    It add complication to logger because not all decorations
>    available for all components and it creates a burden
>    for customer support because all tools would have
>    to support different log formats.
Agreed. Any extra information information could easily be added to the 
actual log message if needed. This is of course only feasible if the 
output is in text format. Examples of user-provided decorations that 
people asked for is gc number, and compiler number.
> 2. Backend might be a better word than adapter.
>
>    STDOUT, STDERR and text file is essentially the same backend.
You're right, these three adapters are all file stream adapters. Its 
only the stream written to that differs. from a configuration point of 
view they are three different targets though. Adapter is used in some 
other logging frameworks, I choose that name to have people recognise it.
>
> 3. I'm not sure we have to care about log rotation by size, time etc -
>     everything is done here during last 20 years, and there are lots of
>     tools that do it.
I think it is very nice to have this simple functionality in the logging 
framework, it removes one external tool dependency when setting up 
logging. But as you say, it is not strictly necessary.
>     But, for file backend, we have to provide jcmd command to close
>     current log and start new one at runtime.
Good idea. I will add this to the JEP somewhere.
>
> 4. Proposed VM API is too verbose and require lots of typing.
>     Also to add new component you have to touch log code, split
>     or rename components is also problematic.
>
>     So it might be better to use
>
>      Log::set_component(Log::gc);
>      Log::warn( format, ... );
>      Log::error();
>      Log::trace();
>      Log::debug()
>
>      Log::start();
>      Log::add( format, ... )
>      Log::commit(Log::level());
The VM API was just an example in the JEP. There are basically no 
loggers defined in the raw implementation. It is up to the developers to 
add loggers/categories when there is a need for it. if you want to you 
can name them a, b and c :)
I cant really see that verbosity is an issue here. I really hope most of 
you are typing fast enough to handle a few more characters. I think the 
readability is more important than the number of character in the name. 
there are enough abbreviated names in the JVM code as it is now. The 
number of lines that are logging are few in comparison with actual code 
lines anyway I think.
Split and rename is only an issue if you aren’t using a modern 
editor/ide to re-factor stuff (hope I didn’t step on any toes here ;) ).
In my poc implementation you only have to add one line of 'code' to have 
a new logger. I used Eclipse when I tried it and it picks up all info to 
provide good contextual help on the spot. I would expect Visual Studio 
and other tools to work equally well. Very easy to use and simple to manage.
> 5.  I'm not sure that transaction is the best term here.
>
> -Dmitry
>
Maybe not, Ill try to find a better word for the buffered logging.

Cheers

/Fredrik