| Re: [jakarta.ee-spec] Proposal: Jakarta Logging |
Hi Werner,
As for the JCP, I doubt with the JDK throwing more and more things out, e.g. SecurityManager, its interest and ability would go anywhere beyond System.Logger in JEP 264: https://openjdk.org/jeps/264 Maybe adding a method or feature here and there, but I doubt, a logging JSR, comparable to say 310 is ever going to happen there.
Since you are citing the success story of JSR 310, might I cite another JSR with a different fate: JSR 305[1] (nullability annotations). As you are probably aware that JSR was never adopted and for a long time a multitude of vendor-specific annotations existed[2] (Jakarta Annotations also has nullability annotations). I personally remember refactoring the nullability annotations a couple of times in my employer's code base, each time we changed the SAST tool.
A couple of years ago, however, a couple of vendors[3] did agree on a common JSpecify specification. It does not have all the bells and whistles of other vendor-specific annotations, but it is widely adopted and I don't have to worry about SAST tool support any more. With this proposal, we are trying to do the same thing: having a group of vendors agree on a common logging API, which would be the greatest common denominator of what is actually used. As Christian said, we believe that common denominator to be SLF4J 2.0. Personally I would concentrate on `LoggerFactory` and leave the sources of context data to the implementors.
From the JDK itself, we don't expect much. I would really love to see `java.util.logging` being retrofitted with `ServiceLoader` support[4], but that could also be solved on the community side if we produce a Jakarta Logging `j.u.l.LogManager` implementation that users could hardcode in their applications. Beyond that I can only expect that `System.Logger` will be adopted by all JDK modules, which is not yet the case.
Piotr
[1] https://jcp.org/en/jsr/detail?id=305
[2] https://stackoverflow.com/q/4963300/11748454
[3] https://jspecify.dev/about/
[4] https://bugs.openjdk.org/browse/JDK-8262741