Java Static Method Equivalents in Kotlin: Companion Objects and Top-Level Functions

Kotlin has no static members because it uses other language features to model shared behavior. You will learn the main alternatives—top-level functions, companion object functions, and singleton object declarations—and how to expose Kotlin APIs conveniently to Java when needed.

Java uses static to attach a method or field to a class rather than to an individual object.

public class TextUtils {
    public static boolean isBlank(String value) {
        return value == null || value.trim().isEmpty();
    }
}

Kotlin separates the different reasons developers use static methods:

• Top-level functions are functions declared directly in a Kotlin file. They are usually the best choice for general utility behavior that does not belong to a particular class.
• A companion object holds behavior logically associated with a class, such as factory methods, constants, and parsing methods.
• An object declaration creates a named singleton. It is useful when shared state or a named service is genuinely needed.
• @JvmStatic is primarily for Java interoperability. It changes how Java callers access a function; Kotlin callers generally do not need it.

This matters because Kotlin code is designed around clear ownership. Instead of automatically putting every utility into a class merely to obtain static, Kotlin lets a function exist without a containing class.

Think of a Java class with static methods as a noticeboard mounted on a building: everyone uses the same board, and nobody needs to enter the building first.

Kotlin offers several places to put that noticeboard:

• A top-level function is a public noticeboard in the file itself.
• A companion object is a noticeboard attached to one specific class.
• An object declaration is one shared office with its own noticeboard and its own stored information.

Choose the location based on who owns the behavior. A text-formatting helper may belong at the top level. A User factory belongs beside User. A shared application configuration service may need a singleton object.

1. Top-level function

Declare a function outside any class:

// TextUtils.kt
fun isBlank(value: String?): Boolean {
    return value == null || value.isBlank()
}

fun main() {
    println(isBlank("   ")) // true
}

This is often the most idiomatic Kotlin replacement for a Java utility class containing only static methods. Kotlin code calls it directly as isBlank(...).

On the JVM, Kotlin compiles this function into a generated class based on the file name. From Java, the default call is TextUtilsKt.isBlank(value).

2. Companion object

Use a companion object when the function conceptually belongs to a class:

class User private constructor(val name: String) {
    companion object {
        fun create(name: String): User {
            require(name.isNotBlank()) {  }
             User(name.trim())
        }
    }
}

 {
     user = User.create()
    println(user.name) 
}

Consider a class factory implemented with a companion object:

class Temperature private constructor(val celsius: Double) {
    companion object {
        fun fromFahrenheit(fahrenheit: Double): Temperature {
            val celsius = (fahrenheit - 32) * 5 / 9
            return Temperature(celsius)
        }
    }
}

fun main() {
    val temperature = Temperature.fromFahrenheit(68.0)
    println(temperature.celsius)
}

Step by step:

1. Temperature has a private constructor, so code outside the class cannot write Temperature(20.0).
2. The companion object provides a class-related creation function named fromFahrenheit.
3. main calls Temperature.fromFahrenheit(68.0) without first creating a Temperature instance.

• Factory methods: Create objects from alternative input formats, such as Money.fromCents(499) or LocalDate.parse("2025-03-08").
• Validation helpers: Use top-level functions such as isValidEmail(value) when they are not owned by one domain class.
• Constants related to a type: Put values such as a maximum allowed length in a companion object.
• Parsing and serialization: Provide Order.fromJson(json) in a companion object when parsing creates an Order.
• Shared services: Use an object for small, stateless coordinators or for a deliberately shared component such as an application logger wrapper.
• Java-compatible libraries: Add @JvmStatic to selected companion functions when Java consumers should call Type.method() rather than Type.Companion.method().

A useful decision rule is to start with the least stateful option.

Utility behavior: top-level functions

For behavior that does not need class state and is not strongly owned by a type, use a top-level function:

fun requireNonEmpty(value: String, fieldName: String): String {
    require(value.isNotBlank()) { "$fieldName must not be blank" }
    return value.trim()
}

Top-level functions avoid Java-style StringUtils or ValidationUtils classes that exist only to hold static methods.

Creation and parsing: companion objects

Use a companion object for factories, parsers, and type-level configuration:

class ApiKey private constructor(val value: String) {
    companion object {
        fun parse(raw: String): ApiKey {
            require(raw.startsWith("key_")) { "Invalid API key" }
            return ApiKey(raw)
        }
    }
}

Treating object as the default replacement for every static method

This works, but can create an unnecessary singleton:

object MathHelpers {
    fun square(number: Int) = number * number
}

If the function has no state and does not belong to a type, a top-level function is simpler:

fun square(number: Int) = number * number

Adding @JvmStatic when Kotlin is the only caller

class User {
    companion object {
        @JvmStatic
        fun guest() = User()
    }
}

This is not wrong, but it is unnecessary for Kotlin callers. Use @JvmStatic only when Java call syntax or a Java framework specifically benefits from it.

Assuming a companion member is truly a Java static member

Without @JvmStatic, Java must access the companion object:

• Kotlin has no static keyword.

• Use a top-level function for a general, stateless utility.

  fun slugify(text: String): String = text.lowercase().replace(" ", "-")
  

• Use a companion object for behavior owned by a class.

  class User private constructor() {
      companion object {
          fun guest(): User = User()
      }
  }
  

• Call companion functions with the class name:

  val user = User.guest()
  

• Use a standalone object for one shared instance:

  object Counter {
      var value = 0
  }
  

Does Kotlin have static methods?

No. Kotlin does not use the static keyword. Top-level functions, companion objects, and object declarations cover the common use cases.

What is the most idiomatic Kotlin replacement for a Java static utility method?

Usually a top-level function, especially when the function has no state and does not naturally belong to a class.

When should I use a companion object in Kotlin?

Use it for operations tied to a type, such as fromJson, parse, create, of, and constants related to that class.

Is a Kotlin companion object the same as Java static?

Not exactly. It is an object associated with a class. Kotlin lets you call its members as ClassName.member(), but Java normally sees it as ClassName.Companion.member() unless @JvmStatic is used.

When do I need @JvmStatic?

Use it when Java code, a Java-based framework, or a Java-facing API needs conventional static access to a companion member. Kotlin callers do not need it.

Can an object contain properties and methods?

Yes. An object is a singleton instance, so it can contain functions and properties, including mutable properties. Use mutable global state carefully.

• Top-level functions — The simplest Kotlin option for stateless utility behavior.
• Companion objects — Provide class-associated factories, parsers, and constants.
• Object declarations — Create named singleton instances.
• @JvmStatic annotation — Improves static-style access from Java.
• const val — Declares compile-time constants, often inside companion objects.
• Kotlin-Java interoperability — Explains how Kotlin declarations appear to Java callers.
• Factory methods — A common reason to use companion object functions.
• Dependency injection — An alternative to global singleton objects for application services.