Hello Romain
Le 2024-03-03 à 17 h 02, Romain Manni-Bucau a écrit :
SystemLogger has the ServiceLoader "pick random first" implementation
which is not what we want
You are describing the behavior of the System.getLogger() method. I was
talking about the use of the System.Logger interface. Nothing force us
to use System.getLogger() for getting an instance of that interface. The
flexibility is the same as before, except that it become possible to use
System.getLogger() if desired.
If we want to drop Log we would rather go to JUL, which stays more
powerful in terms of API, usable in terms of implementation and still
as pluggable as SystemLogger for a runtime like maven.
Yes, I also prefer java.util.logging. I proposed System.Logger because
it has a one-to-one match with the current Maven Log (except in the way
to specify the logging level). It is also less work for creating a
custom implementation, which is apparently what Maven wants (it
basically uses logger as a "println" functionality).
The point about performance is kind of behind now we are java 17 we
have stackwalker so an integration thing but no more the old new
Throwable().getStackTrace() blocker.
I did not talked about performance, but about misleading information
filled in log record. No matter if using stackwalker of exception trace,
is System.Logger or java.util.logging are not used directly in the code,
by default the source class name and source method name reported in the
log record will be the class name / method name of the wrapper (for
example Maven Log class) instead of the name of the place where the log
occurred. We can fix that with java.util.logging at the cost of some
effort, but not with System.Logger (as far as I know).
I tend to agree with your point about N records (N>1) vs 1 record but
this is independent of all log API you mentionned.
I did not said that we need to change the log API for doing that, but
that the fact that the use of System.Logger is more tedious (because of
the way to specify logging level) may not be a bad thing, because it can
be an incentive to fix that.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
