kotlin-logging
kotlin-logging is a lightweight Kotlin wrapper around SLF4J that eliminates boilerplate logging code through lazy-evaluated string lambdas and automatic class-name detection. It supports multiplatform Kotlin (JVM, Android, and experimental targets) and has been actively maintained since 2016.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | oshai/kotlin-logging |
| Owner | oshai |
| Primary language | Kotlin |
| License | Apache-2.0 — OSI-approved |
| Stars | 3.1k |
| Forks | 130 |
| Open issues | 21 |
| Latest release | 8.0.4 (2026-05-27) |
| Last updated | 2026-05-27 |
| Source | https://github.com/oshai/kotlin-logging |
What kotlin-logging is
A SLF4J facade written in pure Kotlin that leverages lambda expressions for deferred message evaluation, reducing overhead when log levels are disabled. Requires users to explicitly provide an SLF4J implementation (logback, log4j, etc.) at runtime; v5+ supports both SLF4J 1.x and 2.x and decouples from the slf4j-api dependency.
Get the kotlin-logging source
Clone the repository and explore it locally.
git clone https://github.com/oshai/kotlin-logging.gitcd kotlin-logging# follow the project's README for install & configurationNeed it deployed, integrated, or customized instead? DEV.co ships production installs.
Best use cases
Implementation considerations
- Requires explicit SLF4J runtime implementation (Logback, Log4j2, SLF4J-Simple); add it as a separate dependency.
- v5+ is not backward compatible with v3/v2/v1; Maven group ID and package names changed; side-by-side migration is possible.
- Multiplatform support is marked experimental; carefully review the wiki and linked issues (#21, #45) before using non-JVM targets.
- Lazy evaluation via lambda expressions `{ }` is the primary performance benefit; ensure team understands this idiom.
- Version 5+ decouples from slf4j-api; projects can mix old and new versions or use it with SLF4J 1.x or 2.x independently.
When to avoid it — and what to weigh
- Java-only projects without Kotlin adoption — If your codebase is pure Java and Kotlin adoption is not planned, direct SLF4J or other Java logging libraries are more straightforward.
- Projects requiring a complete out-of-box logging solution — kotlin-logging is a façade only; it requires explicit configuration and deployment of an underlying SLF4J implementation (Logback, Log4j2, etc.).
- Environments with strict, pre-approved logging stacks — If your organization mandates a specific logging framework, the additional abstraction layer may conflict with governance requirements.
- Performance-critical paths where reflection-based class name detection is costly — Automatic class-name inference uses reflection; manually specifying logger names may be faster in extremely latency-sensitive contexts.
License & commercial use
Licensed under Apache License 2.0 (Apache-2.0), a permissive OSI-approved license permitting commercial use, modification, and redistribution under the stated conditions.
Apache-2.0 is a permissive, OSI-approved open-source license. Commercial use is permitted provided the license text and attribution are included in distributions. No warranty or liability is assumed by the licensor. Recommend reviewing your organization's legal policy on Apache-licensed dependencies.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Strong |
| License clarity | Clear |
| Deployment complexity | Low |
| DEV.co fit | Strong |
| Assessment confidence | High |
No known critical vulnerabilities highlighted in provided data. As a logging façade, security posture depends on the underlying SLF4J implementation and user configuration (e.g., logging sensitive data accidentally, unvalidated serialization in log payloads). Standard SLF4J security practices apply. No formal security audit or CVE history is stated in the data provided.
Alternatives to consider
SLF4J (direct use)
Simpler if logging boilerplate is acceptable; widely adopted; no Kotlin-specific abstractions; more verbose syntax.
Log4j2 Kotlin DSL or Logback
Direct native integration with logging implementations; potentially less indirection; requires more manual configuration compared to kotlin-logging's auto-detection.
java.util.logging (JDK built-in)
Zero external dependencies; part of JDK; limited features and less idiomatic in Kotlin; suitable for simple use cases only.
Build on kotlin-logging with DEV.co software developers
kotlin-logging eliminates logging boilerplate in Kotlin/JVM and multiplatform projects. Choose your SLF4J implementation (Logback, Log4j2, etc.), integrate the JAR, and use idiomatic Kotlin logging syntax. Review the wiki and examples for multiplatform or Android use cases.
Talk to DEV.coRelated open-source tools
Surfaced by semantic similarity across the DEV.co open-source index.
Related on DEV.co
Explore the category and the services that help you build with it.
kotlin-logging FAQ
Do I need to specify the class name when creating a logger?
What SLF4J implementation should I use?
Is kotlin-logging backward compatible?
Can I use kotlin-logging on Android or non-JVM platforms?
Custom software development services
DEV.co is a software development agency delivering custom software development services to companies building on open source. Our software developers and web developers design, integrate, and ship production systems — spanning web development, APIs, AI, data, and cloud. If kotlin-logging is part of your open-source observability roadmap, our team can implement, customize, migrate, and maintain it.
Evaluate kotlin-logging for your Kotlin project
kotlin-logging eliminates logging boilerplate in Kotlin/JVM and multiplatform projects. Choose your SLF4J implementation (Logback, Log4j2, etc.), integrate the JAR, and use idiomatic Kotlin logging syntax. Review the wiki and examples for multiplatform or Android use cases.