Le 2024-03-03 à 18 h 48, Romain Manni-Bucau a écrit :
(snip) Nothing force us to use System.getLogger() for getting an
instance of that interface. (snip)
Yes but you make something well specified misbehaving so while
technically true I think it would deserve us on the long run.
I do not understand this argument. The proposal is to replace a custom
interface by a standard one doing the same thing. How to get an instance
of that interface does not need to change. This is currently done that
way in Maven Mojos:
@Inject
protected Log logger
It would stay as before, except that Log would become System.Logger.
Where do you see a misbehaviour?
I did not talked about performance, but about misleading information
filled in log record (snip).
For me it means a bug in the implementation
It is not a bug. When a logger uses stackwalker for determining who is
logging, it stops at the first stack frame which is not a method
internal to the logger implementation. It has no way to know that it
should continue a few more frames further. There is no API for saying
"please ignore stack frames that are inside the Maven Log class".
When using java.util.logging, we can override the automatic detection by
our own. But this is more work, e.g. we have to replace all calls to a
Logger.log(…) method by a call to our custom method which will override
the LogRecord default values. However 1) we cannot do that with
System.Logger, and 2) we don't need this complication at all if we just
use the logger directly, without passing through a Maven custom interface.
So overall I'm not sure the goal,
For example when Maven is run with the --debug flag, it could use the
logger provided by System.getLogger() instead of the Maven default
"println-like" logger. We may lost coloration, but each log message
would be preceded by a line telling which method in which class emitted
that log. This is very useful when there is no exception stack trace but
we still want to look in the code what is going on.
Martin
