Le lun. 4 mars 2024 à 10:49, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> 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. > As any interface you can also change it - and trust me I'm one of those who did it a lot ;) - but it is also always misleading to end user to get an instance which does not come from the expected factory if this one has a standard and here it is the finder. So technically feasible but I'm not convinced it would be sane for end user and, again, the point is that it does not help on the topic. > > > > "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? > Being maven owned and abstracted from a standard which moves. We can make log contextual whereas if we implement the standard we need to...implement it, any method, any version. This just does not work, the famous slf4j standard beat us already and JVM makes its API evolving so it can break us any time, check out Stream usage in CDI (Instance) for an example. So we need a maven owned abstraction. > > > > 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". > Hmm, I don't see much issue there, for me whatever we do we'll end up in current state more or less cause it is the need even if not as neat as we all would like and splitting would be worse cause mix the API and make it even more complicated for consumers so not sure I'm keen to have 2 API. Maybe a stream redirector to the logging API in a shared module can help but will end in the same layers IMHO. > > > > @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. > Yes and not, it is literally a design constraint of the JVM from my window cause it must be used for low level/bootstrap log so no real choice than putting it in lang and opening it. When it popped out a lot of backend tried to use it primarly but today it is a dead topic, not sure there was a lot of pitfall except the fact it is an api without backend but the main blocker for me would be the lifecycle and fact we loose the guarantee of instrumentation kind of forcing people to await for next release to upgrade which is something we don't impose as of today and I think it is good to be able to adopt new jvm releases faster, even if it sometimes needs some hack in dependencies, rather than awaiting. Indeed just my opinion but for me the ROI is > to keep our API. > > But anyway, as said before, this is not very important so I give up. > > Martin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
