Le dim. 3 mars 2024 à 17:50, Martin Desruisseaux < [email protected]> a écrit :
> 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. > Yes but you make something well specified misbehaving so while technically true I think it would deserve us on the long run. > > > > 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). > JUL is quite easy - very easy now we have stackwalker ;) - so I don't think it would have been a blocker by itself. > > > > 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). > For me it means a bug in the implementation so no more an issue than doing a logger.severe instead of info in mavenLog.info. So maybe not a blocker? > > > > 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. > Ok but this is not linked to a specific logger AFAIK. So overall I'm not sure the goal, replace slf4j? (if so i would support you ;)) > > Martin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
