Kotlin Class vs Object: Why Java Static Methods Convert to object

A Kotlin class is a blueprint from which you can create many instances. A Kotlin object creates exactly one shared instance: a singleton. Android Studio converted the Java type to an object because the original class contained only a static utility method. Kotlin has no static keyword, and an object is one way to group functionality that does not need per-instance state.

You will also learn when a top-level function or a companion object is a better Kotlin design.

In Java, static members belong to the class itself, not to an instance:

MyClass.generateChecksumCrc16(data);

A Java class that contains only static methods is often used as a utility class. You do not create new MyClass() to call its methods.

Kotlin does not have the static keyword. Instead, it provides several choices depending on what the code represents:

• class: a reusable blueprint. Each constructor call creates a separate object.
• object declaration: one automatically created, globally accessible instance. This is the singleton pattern.
• companion object: an object associated with a class; useful for factory methods, constants, and APIs conceptually owned by that class.
• Top-level declaration: a function or property directly in a Kotlin file. This is often the simplest choice for a standalone utility function.

The converted Java class had no instance fields, constructor use, or instance methods. Its only method was static, so it did not need multiple MyClass instances. The converter chose:

object MyClass

That lets callers use nearly the same style:

val checksum = MyClass.generateChecksumCrc16(bytes)

Unlike Java's static, an object is still a real object. It can implement interfaces, hold state, and be passed as a value. Because it has one shared instance, mutable state inside an object must be handled carefully, especially in concurrent code.

Think of a class as a cookie cutter. You can use one cutter to make many cookies, and each cookie is a separate object with its own data.

class User(val name: String)

val firstUser = User("Asha")
val secondUser = User("Mateo")

Think of an object as a single shared noticeboard. There is one noticeboard for everyone; you do not create another one each time you need it.

object AppSettings {
    var darkMode = false
}

A CRC calculation utility does not need a separate identity or stored data for every caller. It is closer to a shared tool on the wall, which is why an object can fit it.

A regular class defines properties and behavior for instances:

class Counter {
    var value = 0

    fun increment() {
        value++
    }
}

val first = Counter()
val second = Counter()

first.increment()
println(first.value)  // 1
println(second.value) // 0

first and second are different objects, so their value properties are independent.

An object declaration defines one singleton instance:

object ChecksumUtils {
    fun isValidByteCount(bytes: ByteArray): Boolean {
        return bytes.isNotEmpty()
    }
}

val valid = ChecksumUtils.isValidByteCount(byteArrayOf(1, 2, 3))

You do not write ChecksumUtils(). Kotlin creates the sole instance automatically.

For a standalone utility function, a top-level function is often more idiomatic:

fun generateChecksumCrc16(bytes: ByteArray): Int {
    var crc = 0xFFFF

    for (aByte in bytes) {
        var crcByte = aByte.toInt()

        repeat(8) {
            val temp = (crc shr 15) xor (crcByte shr 7)
            crc = (crc shl 1) and 0xFFFF

            if (temp > 0) {
                crc = (crc xor 0x1021) and 0xFFFF
            }

            crcByte = (crcByte shl 1) and 0xFF
        }
    }

    return crc
}

val checksum = generateChecksumCrc16(byteArrayOf(0x01, 0x02))

Top-level functions can be called directly within Kotlin, without a utility class name.

Consider this singleton:

object RequestIds {
    private var nextId = 1

    fun newId(): Int {
        val id = nextId
        nextId++
        return id
    }
}

val first = RequestIds.newId()
val second = RequestIds.newId()

Execution proceeds as follows:

1. object RequestIds declares one singleton instance. No code calls RequestIds().
2. nextId starts as 1 inside that one instance.
3. RequestIds.newId() calls a function on the singleton.
4. On the first call, id receives 1, then nextId becomes 2; the function returns 1.
5. On the second call, the same singleton is used. id receives 2, then nextId becomes 3; the function returns 2.

By contrast, each Counter() call for a regular class would create a separate value property.

For the CRC code, the variables crc, temp, and crcByte are local variables inside the function. Every call gets fresh local values, even though the function belongs to an object.

Use a class when each item needs its own state or identity:

• A User, Order, SocketConnection, or GameCharacter.
• A parser configured differently for different inputs.
• A service that receives dependencies through its constructor.

Use an object when exactly one shared instance makes sense:

• An application-wide configuration holder, preferably immutable after setup.
• A stateless utility group when a top-level function is not appropriate.
• An implementation of an interface that has no per-instance state.
• A logger or a sealed hierarchy member.

interface Formatter {
    fun format(value: Int): String
}

object HexFormatter : Formatter {
    override fun format(value: Int): String = value.toString(16)
}

Use a top-level function for simple operations such as checksum calculations, string transformations, or data conversions:

fun normalizeEmail(email: String): String = email.trim().lowercase()

Use a companion object when behavior belongs to a particular type:

class User private constructor(val name: String) {
    companion object {
        fun guest(): User = User("Guest")
    }
}

val guest = User.guest()

In Kotlin projects, utility code is commonly kept as top-level functions rather than Java-style static utility classes:

// Crc16.kt
fun generateChecksumCrc16(bytes: ByteArray): Int {
    // calculation
    return 0
}

A class is usually chosen when it owns dependencies or configuration:

class Crc16Calculator(private val initialValue: Int = 0xFFFF) {
    fun calculate(bytes: ByteArray): Int {
        var crc = initialValue
        // calculation
        return crc
    }
}

This design makes different configurations explicit and improves testability.

A companion object is common for factories, constants, and validation that is strongly associated with a type:

class ApiKey private constructor(val value: String) {
    companion object {
        fun from(value: String): ApiKey {
            require(value.isNotBlank()) { "API key cannot be blank" }
            return ApiKey(value)
        }
    }
}

Use singleton objects cautiously when they contain mutable state. Hidden global state can make tests influence one another and can cause thread-safety problems. Prefer passing dependencies into classes when the object represents a service with replaceable behavior.

For Java callers, Kotlin top-level functions compile to static methods in a generated file class. An object method is normally called from Java through MyObject.INSTANCE.method(). Add @JvmStatic when Java callers need static-style access from an object or companion object.

Trying to instantiate an object

This does not compile because an object already has its one instance:

object ChecksumUtils

// val utils = ChecksumUtils() // Error

Use the object's name directly:

val utils = ChecksumUtils

Usually, call its function directly instead:

ChecksumUtils.generateChecksumCrc16(bytes)

Using a class for static-style code without a companion object

A regular class method requires an instance:

class ChecksumUtils {
    fun calculate(bytes: ByteArray): Int = bytes.size
}

val value = ChecksumUtils().calculate(bytes)

This is valid, but creating an instance solely to call a stateless helper is often unnecessary. Prefer a top-level function, an object, or a companion object based on ownership.

Treating an object as automatically thread-safe

Kotlin initializes an object safely, but mutable properties still need proper synchronization or a safer design when multiple threads update them:

object Statistics {
    var requests = 0

    fun recordRequest() {
        requests++ // Not automatically safe for concurrent updates
    }
}

Avoid mutable global state where possible.

Using object for data that should have multiple instances

object User {
    var name = ""
}

This represents only one user for the whole program. Use a class instead:

class User(val name: String)

Forgetting Kotlin byte conversion details

Byte is signed in Kotlin, ranging from -128 to 127. The conversion aByte.toInt() preserves the signed value. CRC algorithms often mask shifted values with and 0xFF, as the converted code does, to keep the intended lower eight bits.

A companion object is not the same as Java static, even though Kotlin lets you call it with the class name:

class Connection {
    companion object {
        const val DEFAULT_PORT = 443
    }
}

println(Connection.DEFAULT_PORT)

Internally, the companion is still an object associated with Connection.

// Many independent instances
class User(val name: String)
val user = User("Asha")

// Exactly one instance
object AppConfig {
    const val API_VERSION = "v1"
}
println(AppConfig.API_VERSION)

// Behavior associated with a type
class UserId private constructor(val value: String) {
    companion object {
        fun create(value: String) = UserId(value)
    }
}
val id = UserId.create("u-42")

// Standalone utility, often preferred
fun generateChecksumCrc16(bytes: ByteArray): Int = 0

• Kotlin has no static keyword.
• Use class when callers need multiple objects with separate state.
• Use object for one shared instance.
• Do not call an object with parentheses.
• Prefer top-level functions for small, stateless utilities.
• Use a companion object for constants, factories, and type-related operations.
• Avoid mutable state in singleton objects unless its lifetime and concurrency are deliberately managed.
• For Java-friendly static access from an object or companion, use @JvmStatic when needed.

Why did Android Studio convert my Java class to a Kotlin object?

Your Java class had only a static method. Since Kotlin has no static keyword, the converter used a singleton object so the method can still be called as MyClass.generateChecksumCrc16(bytes).

Is Kotlin object the same as Java static?

Not exactly. Java static members belong to a class and do not require an object instance. A Kotlin object is a real singleton instance. It often serves a similar purpose for utility code.

Should I use an object for every utility method in Kotlin?

Usually no. A top-level function is often simpler for a standalone, stateless operation. Use an object when grouping related behavior or representing a genuine singleton improves clarity.

Can a Kotlin object have properties and functions?

Yes. It can contain properties, functions, implement interfaces, and have initialization code. Its properties are shared because there is only one instance.

Can I create multiple instances of a Kotlin object?

No. An object declaration defines exactly one instance. Use a class when you need multiple instances.

When should I use a companion object?

Use one for behavior strongly associated with a class, such as factory functions, constants, or parsing methods like UserId.from(value).

Can Java call functions in a Kotlin object?

Yes. Java normally accesses the singleton through MyObject.INSTANCE. You can annotate suitable functions with @JvmStatic to provide static-style Java access.

Does object make my code thread-safe?

Object initialization is safe, but mutable state inside the object is not automatically safe for concurrent updates.

• Kotlin companion objects — provide class-associated functions and constants without Java's static keyword.
• Top-level functions — an idiomatic option for stateless utility functions such as checksum calculations.
• Singleton pattern — the design pattern directly represented by an object declaration.
• Kotlin constructors — explain how regular classes create independent instances.
• Kotlin visibility modifiers — control whether classes, objects, functions, and properties are accessible outside a file or module.
• Java interoperability — useful when Kotlin object, @JvmStatic, and top-level functions are called from Java.
• Immutability and shared state — important when a singleton stores properties used by many parts of an application.