DEV.co
Open-Source Observability · scala-garden

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.

Source: GitHub — github.com/scala-garden/scala-logging
926
GitHub stars
127
Forks
Scala
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositoryscala-garden/scala-logging
Ownerscala-garden
Primary languageScala
LicenseApache-2.0 — OSI-approved
Stars926
Forks127
Open issues30
Latest releasev3.9.6 (2025-09-16)
Last updated2026-05-07
Sourcehttps://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).

Quickstart

Get the scala-logging source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/scala-garden/scala-logging.gitcd scala-logging# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

High-frequency logging in performance-sensitive Scala services

Macro-based check injection avoids repeated runtime condition evaluation. Ideal for microservices, data processing pipelines, and request handlers where debug/trace logging is verbose but should not impact production performance.

Scala 2/3 codebases requiring contextual logging (correlation IDs, request IDs)

LoggerTakingImplicit and CanLog trait enable passing context through implicit parameters without threading it explicitly. Cleanly integrates MDC setup/teardown for distributed tracing.

JVM projects integrating third-party tools that parse log formats (Sentry, ELK, etc.)

Built-in string interpolation → SLF4J placeholder conversion ensures tools that group on message format (not interpolated values) work correctly without custom formatters.

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.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityLow
DEV.co fitGood
Assessment confidenceHigh
Security considerations

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.

Software development agency

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.co

Related 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?
No (by design). Macros expand at compile time, injecting isDebugEnabled checks. The generated code is equivalent to hand-written conditionals. Zero macro runtime cost; only SLF4J backend cost remains.
Can I use this in a Java module of a mixed Scala/Java project?
No. scala-logging requires Scala compiler for macro expansion. Java modules cannot invoke Scala macros. Java code must use SLF4J directly. Scala modules can wrap and expose SLF4J loggers to Java if needed.
What happens if I log an exception and use string interpolation?
Documented limitation: the macro cannot rewrite s-strings when an exception is also passed. You must use SLF4J placeholder syntax (logger.error('msg: {}', arg, exception)) for that case.
Is this library production-ready?
Yes. Used in production by many Scala teams. Community-maintained, not under Lightbend SLA. Requires team capability to troubleshoot and contribute fixes independently. No paid support.

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.