scala-logging
Scala Logging is a lightweight wrapper around SLF4J that uses Scala macros to eliminate boilerplate and improve performance. It automatically injects log-level checks at compile time, so developers can write clean logging code without manual conditionals.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Repository | scala-garden/scala-logging |
| Owner | scala-garden |
| Primary language | Scala |
| License | Apache-2.0 — OSI-approved |
| Stars | 926 |
| Forks | 127 |
| Open issues | 30 |
| Latest release | v3.9.6 (2025-09-16) |
| Last updated | 2026-05-07 |
| Source | https://github.com/scala-garden/scala-logging |
What scala-logging is
Built on SLF4J, scala-logging employs Scala macros to generate isDebugEnabled/isInfoEnabled checks at compile time, eliminating runtime overhead. Supports Scala 2.12, 2.13, and 3.0; requires Java 11+ (3.x for Java 8); integrates with any SLF4J-compatible backend (Logback recommended).
Get the scala-logging source
Clone the repository and explore it locally.
git clone https://github.com/scala-garden/scala-logging.gitcd scala-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 SLF4J-compatible backend (e.g., Logback 1.4.14+). Scala Logging 4.x requires SLF4J 2.x; 3.x for SLF4J 1.x. Verify version alignment in build tool.
- Choose between LazyLogging (for frequently instantiated classes), StrictLogging (singletons/always-used), or AnyLogging (trait abstractions) based on instantiation pattern.
- Macro rewrite of s-strings to SLF4J placeholders works only when interpolation is directly in log call. Pre-built strings bypass this and lose the benefit.
- Ensure Scala compiler is up-to-date; macro expansion relies on Scala compiler internals. 2.12, 2.13, and 3.0 are supported; Scala 2.10 requires older 2.x branch.
- For contextual logging (CorrelationId, RequestId), implement CanLog trait and pass via implicit; integrates cleanly with MDC but requires discipline in implicit scope management.
When to avoid it — and what to weigh
- Project is Java-only or non-JVM — scala-logging is Scala-specific. Pure Java projects should use SLF4J directly; non-JVM languages cannot use it.
- Logging backend already chosen is not SLF4J-compatible — scala-logging wraps SLF4J exclusively. If locked into a non-SLF4J backend (proprietary, custom), this library cannot be used.
- Exception logging with string interpolation required — Documented limitation: the macro cannot rewrite s-strings when logging exceptions and messages together. Must fall back to SLF4J placeholders manually in those cases.
- Real-time log filtering or dynamic level changes critical to deployment — Macro expansion happens at compile time. Log-level decisions are baked in; changing levels at runtime requires recompile. Not suitable if runtime log-level tuning is a core requirement.
License & commercial use
Apache License 2.0 (Apache-2.0). Permissive OSI license; grants rights to use, modify, distribute, and sublicense under terms stated. No patent retaliation clause. Commercial use explicitly permitted.
Apache-2.0 explicitly permits commercial use. No per-seat fees, no proprietary restrictions. Include a copy of the license and state material changes. Safe for proprietary products. Verify compliance team is comfortable with open-source attribution requirements.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | Low |
| DEV.co fit | Good |
| Assessment confidence | High |
No network calls, no external dependencies beyond SLF4J and backend. Security posture depends entirely on SLF4J backend (Logback, etc.). Macro expansion happens at compile time; no runtime code generation. Ensure backend is not misconfigured to log sensitive data (passwords, tokens) unencrypted. String interpolation rewrite does not alter security properties; same data flows through.
Alternatives to consider
SLF4J (bare)
Direct SLF4J avoids another layer and Scala-specific macros. More verbose (manual isDebugEnabled checks) but simpler, language-agnostic, and compatible with Java/Kotlin teams. Heavier cognitive load for debug-level logging in hot paths.
Logback/Log4j2 (direct)
Skip SLF4J abstraction entirely. Possible if logging backend is fixed. Tighter control, no wrapper overhead, but locks in to one backend; harder to swap later. Requires manual level checks; less idiomatic for Scala.
Zio Logging or other Scala-native frameworks
Functional programming approach with effect tracking (ZIO, Cats Effect). Better for pure FP codebases; offers structured logging and async safety. Steeper learning curve; overkill for simple logging needs.
Build on scala-logging with DEV.co software developers
Our engineers can assess scala-logging's fit for your codebase, help optimize macro usage, and guide SLF4J backend integration. Contact us for a technical review.
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.
scala-logging FAQ
Does scala-logging add runtime overhead?
Can I use this in a Java module of a mixed Scala/Java project?
What happens if I log an exception and use string interpolation?
Is this library production-ready?
Software development & web development with DEV.co
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 scala-logging is part of your open-source observability roadmap, our team can implement, customize, migrate, and maintain it.
Evaluating Scala logging for your next project?
Our engineers can assess scala-logging's fit for your codebase, help optimize macro usage, and guide SLF4J backend integration. Contact us for a technical review.