kotlin-logging version 4.x: breaking changes
oshai opened this issue · comments
As part of a revamp to the library I am considering some breaking changes, or api's that should be added / removed:
- remove slf4j from the jvm signature (ie, will not implement slf4j Logger interface) and replace is with similar KLogger interface.
- do we need to add fluent logging support?
- change artifact name for jvm version to allow split: slfj/log4j/android etc'.
- remove api of mu.KLoggable in favour of KotlinLogging.logger {}
about 5k refs at: https://github.com/search?q=%22mu.KLogging%22&type=code - do we need inline of logging methods?
I am basically considering two conflicting approaches
- keep the lib slf4j compliant.
- allow better multiplatform/android support.
Any feedback is appreciated.
I'd love to keep using kotlin-logging on the JVM with good integration of common JVM logging frameworks (lslf4j, log4j2).
Thanks for the feedback!
Generally, the idea I have is as such:
Today in the jvm we have KLogger which extends org.slf4j.Logger (by delegation). The nice thing about it is that we get "for free" all current slf4j impl.
The disadvantage is that in multiplatform we currently can't have a jvm impl which is not slfj (for example going directly to log4j2 api without slf4j).
The main issue is with Android, where slf4j support is not as good (see #122).
The idea is that slf4j will still be supported, but instead of inheritance it will be via wrapping it. This is a breaking change of course, but it should still work seamless with slf4j.
The disadvantages of that approach:
- The jvm code will be more complicated (and more code).
- We will have yet another facade to a facade.
From the user perspective change is not big. Main change will be that we will need some kind of "discovery" to where to redirect the log messages (similar to what slf4j have for example).
We will still have to figure out implementation issues like: - is inline supported and how?
- are we supporting fluent api like slf4j2? is it relevant to kotlin?
- location awareness (line of log).
Hope that is clear. More thoughts are welcome.
One of the options I am considering is moving to java.util.logging. Turns out it has some location support with logp.
After reading a bit more in here and some other resources I think that:
- The JVM situation is a bit fragmented:
- On the server slf4j is still the best choice.
- On android slf4j is not the best options - jul / native logging are better.
The current direction I have is to keep the dependency on slf4j (maybe with some changes to visible factories), but allow also other logging framewoks via system properties.
In addition, change all the api's of the lib to be "self-contained" and not dependent on slf4j.
I release an initial version 4.0.0-beta-1. Please try it.
The expected required changes are mostly for imports:
import mu.
Should be changed to:
import mu.two
Release 4.0.0-beta-2 with artifact names change to kotlin-logging-mew.
Instructions to try:
Gradle
implementation 'io.github.oshai:kotlin-logging-jvm:4.0.0-beta-9'
Logger:
import io.github.oshai.KotlinLogging
private val logger = KotlinLogging.logger {}
Do you know when 4 final would be released ?
I am looking at the stats from time to time, and still need to do some checks on my apps.
So currently plan to release in June/July.
Thanks for reply. For what it's worth we're running this at scale on beta 28 and it seems solid.
I'd be very happy to see the logging methods are inlined to avoid unnecessary performance impacts mentioned in #34 (comment)
I'd be very happy to see the logging methods are inlined to avoid unnecessary performance impacts mentioned in #34 (comment)
The problem with inlining is that it doesn't work well with the current approach of embedding line numbers in the log message (slf4j does that in runtime). So at the moment this is not planned to be added.
Seems like the package name is missing the lib name. So I am going to do another (breaking) change of package rename:
io.github.oshai -> io.github.oshai.kotlinlogging.
Version 4.0 released!