Note: this logging issue is not very important. If there is such
resistance against it, I will not insist.
Le 2024-03-04 à 08 h 35, Romain Manni-Bucau a écrit :
Please read
https://docs.oracle.com/javase%2F9%2Fdocs%2Fapi%2F%2F/java/lang/System.LoggerFinder.html
I have already read that. The idea that System.Logger instance MUST be
obtained thought a LoggerFinder is your own interpretation not backed by
any statement in the Javadoc. For me, it is as valid as saying that
Java.nio.file.Path instances MUST be obtained by calls to Path.of(...),
that java.io.PrintStream instances MUST be System.out or System.err,
etc. If I'm wrong, please point us to the exact sentence in the contract.
"But System.Logger is the same compromise and is as suitable as Log."
this is nonsense to me since it is strictly equivalent in terms of API
but not in terms of maven guarantee and stability for plugin writers"
Please elaborate: why a Maven interface would provide more stability
guarantees than a standard Java interface in which all methods are
equivalent? A reason other than claiming that using a System.Logger
instance not provided by LoggerFinder would break applications, unless
you can demonstrate that.
"However, there is nothing in System.Logger, System.getLogger() or
System.LoggerFinder javadoc saying that we should not use it." - cause
you don't care about the issue maven api solves for now.
What are the issues that Maven API solves that an equivalent standard
interface does not solve? "Stability" is vague. Can you give an example?
Also "Maven, which need more than println but not as much as a real
logging framework" is wrong, this is only the local case for a subset
of plugins, anything else needs a real logging system and mvnd too.
Okay. But it can be a two steps process. First use the standard
interface when it fits the exact same purpose than the Maven interface,
and later separate "logging" from "console output".
@Pavel: exactly cause the API is only a part of the solution, the
lifecycle is another one and there System.Logger fills another gap the
JVM had and was using System.out before as explained in the first
responses.
The fact that System.Logger fills a gap does not mean that it is not
intended to be used for any other purpose. The LoggerFinder javadoc
mentions "Libraries and classes that only need loggers". The fact that
the interface was added in `java.lang` package suggests that it is
intended to be used. E.g., it is a way for libraries to keep the
"java.logging" module optional.
But anyway, as said before, this is not very important so I give up.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
