Idiomatic Logging in Kotlin: Companion Objects, Properties, and Best Practices

By the end of this page, you will understand how Kotlin handles class-level logging without Java-style static fields. You will learn the most common Kotlin logging patterns, when to use a companion object, how top-level or delegated approaches can help, and what developers typically do in real Kotlin codebases.

In Java, logging is often stored in a static final field so that one logger instance is shared by the class. Kotlin does not have static members in the same form, but it provides several alternatives that serve the same purpose.

The most common Kotlin replacement is a property inside a companion object. A companion object belongs to the class rather than to individual instances, so it is the closest equivalent to a Java static member.

For example:

class Foo {
    companion object {
        private val log = LoggerFactory.getLogger(Foo::class.java)
    }
}

This matters because logging is usually:

• shared by all instances of a class
• created once and reused
• tied to the class name for filtering and debugging

In real programs, loggers help you:

• track application flow
• record errors and warnings
• debug production issues
• monitor important events

In Kotlin, the goal is not to imitate Java syntax exactly, but to use Kotlin features to express the same idea clearly and safely.

Think of a logger as a notebook assigned to a class.

• If every object instance had its own notebook, you would waste space and repeat setup.
• Instead, the whole class shares one notebook.
• In Java, that shared notebook is often stored in a static field.
• In Kotlin, the companion object is the shared shelf where that notebook lives.

So a companion object is like a shared storage area for things that belong to the class itself, not to each object created from the class.

The most common Kotlin logging syntax uses a companion object.

import org.slf4j.Logger
import org.slf4j.LoggerFactory

class Foo {
    companion object {
        private val log: Logger = LoggerFactory.getLogger(Foo::class.java)
    }

    fun doWork() {
        log.info("Work started")
    }
}

Why this works

• companion object holds values shared by the class
• private val means the logger cannot be changed and is only visible inside the class
• Foo::class.java gets the Java Class object required by many logging libraries

Another common style

Some developers put the logger directly in the companion object without explicitly writing the type:

class Foo {
    companion object {
        private val log = LoggerFactory.getLogger(Foo::.java)
    }
}

Consider this example:

import org.slf4j.LoggerFactory

class PaymentService {
    companion object {
        private val log = LoggerFactory.getLogger(PaymentService::class.java)
    }

    fun process(amount: Int) {
        log.info("Processing payment: {}", amount)
    }
}

What happens step by step

1. The PaymentService class is loaded.
2. Its companion object is created.
3. The log property is initialized once using LoggerFactory.getLogger(PaymentService::class.java).
4. When process(100) is called, the method uses the shared log instance.
5. The logging framework records a message associated with the PaymentService class.

Important detail

Even if you create many PaymentService objects, they all use the same logger stored in the companion object.

Logging in Kotlin is used in many real applications.

Web applications

class UserController {
    companion object {
        private val log = LoggerFactory.getLogger(UserController::class.java)
    }

    fun createUser(username: String) {
        log.info("Creating user: {}", username)
    }
}

Useful for tracking incoming requests and important actions.

Background jobs

class EmailJob {
    companion object {
        private val log = LoggerFactory.getLogger(EmailJob::class.java)
    }

    fun run() {
        log.info("Email job started")
    }
}

Useful for cron jobs, schedulers, and batch tasks.

Error reporting

class FileImporter {
    companion  {
          log = LoggerFactory.getLogger(FileImporter::.java)
    }

     {
         {
            
        }  (e: Exception) {
            log.error(, path, e)
        }
    }
}

In real Kotlin projects, developers usually choose one of a few patterns.

1. Companion object logger

This is the most direct replacement for Java static loggers.

class OrderService {
    companion object {
        private val log = LoggerFactory.getLogger(OrderService::class.java)
    }
}

Use this when you want a clear class-level logger with minimal magic.

2. Base helper or generic logger function

Teams often reduce repetition with a helper:

inline fun <reified T> logger() = LoggerFactory.getLogger(T::class.java)

class OrderService {
    companion object {
        private val log = logger<OrderService>()
    }
}

This improves consistency across many classes.

3. Instance property logger

Sometimes developers use an instance-level property:

class OrderService {
      log = LoggerFactory.getLogger(javaClass)
}

1. Creating a logger per instance when a class-level logger is enough

Broken style:

class Foo {
    private val log = LoggerFactory.getLogger(Foo::class.java)
}

This is not always wrong, but it is usually unnecessary if all instances can share one logger.

Better:

class Foo {
    companion object {
        private val log = LoggerFactory.getLogger(Foo::class.java)
    }
}

2. Using the wrong class reference

Broken code:

class Foo {
    companion object {
        private val log = LoggerFactory.getLogger(String::class.java)
    }
}

This logger will be named for String, not Foo.

Better:

class  {
      {
          log = LoggerFactory.getLogger(Foo::.java)
    }
}

Companion object vs instance logger

import org.slf4j.LoggerFactory

class Foo {
    companion object {
        private val log = LoggerFactory.getLogger(Foo::class.java)
    }
}

Quick rules

• Use companion object for a class-level logger
• Use val, not var
• Usually make the logger private
• Use Foo::class.java to pass the class to Java logging libraries
• Prefer parameterized messages:
  • log.info("User id: {}", id)
  • not log.info("User id: " + id)

Useful helper

inline fun <reified T> logger() = LoggerFactory.getLogger(T::class.java)

Usage:

What is the Kotlin equivalent of a static logger?

The usual equivalent is a val inside a companion object. It gives you one shared logger for the class.

Is companion object the idiomatic way to define a logger in Kotlin?

Yes, it is one of the most common and widely accepted patterns, especially when using Java logging libraries like SLF4J.

Can I create the logger as a normal property instead?

Yes, but that creates an instance property rather than a class-level property. It is usually less desirable unless you specifically need instance-based behavior.

Why do Kotlin examples use Foo::class.java?

Many logging libraries are Java libraries and expect a Java Class object. Foo::class.java converts the Kotlin class reference into the Java form.

Should the logger be private?

Usually yes. Other classes normally do not need direct access to another class's logger.

Should I name the logger log or logger?

Either is fine. log is very common because it is short and readable.

Is there a built-in logger in Kotlin?

No. Kotlin itself does not include a built-in general-purpose logging API. Projects usually use libraries such as SLF4J with Logback or Log4j.

• Companion objects — They are Kotlin's main replacement for Java-style static members.
• Properties in Kotlin — Loggers are usually stored as val properties.
• val vs var — Loggers should normally be immutable, so val is preferred.
• Class references in Kotlin — Foo::class.java is needed when calling Java libraries.
• SLF4J logging — A common logging API used from Kotlin and Java.
• Exception handling — Logging is often used inside try/catch blocks.
• Singleton objects — Kotlin object declarations can also hold shared loggers.
• Interoperability with Java — Logging is a good example of Kotlin code calling Java libraries.