Exclamation Mark in Kotlin: Hidden Optimization or Compromise?

Single Exclamation Mark in Kotlin: What Hides Behind One Symbol?

Have you ever seen Kotlin code like String! and wondered: "What's that exclamation mark? An error? A new feature?". If so — you are not alone. The question about single exclamation mark in Kotlin gathers thousands of views on Stack Overflow, and for good reason. The topic seems simple, but behind one symbol lies a whole layer of knowledge about the type system, interaction with Java, and, most interestingly, about performance.

In this article, we will not just explain what ! is in Kotlin. We will break down how this mechanism affects the speed of your application, when its use is justified, and when it's better to stay away. Ready to look under the hood of Kotlin? Let's go!

What is the Single Exclamation Mark in Kotlin? (Platform Types)

Let's start with the basics. Single exclamation mark (or simply !) in Kotlin is not an operator you can write in code. It is a marker that appears in compiler messages, the IDE, and generated code to denote so-called platform types.

When Kotlin interacts with Java, it doesn't know whether a variable can be null or not. Java has no strict separation into nullable and non-null types. To solve this problem, Kotlin introduces platform types — types that can be either nullable or non-null. They are denoted by the exclamation mark.

For example, if a Java method returns String, Kotlin will show it as String!. This means: "I'm not sure if it can be null, be careful".

What does it look like in code?

// Java code\npublic class JavaClass {\n    public static String getName() {\n        return "Kotlin";\n    }\n}\n\n// Kotlin code\nval name: String! = JavaClass.getName() // IDE shows String!\nprintln(name.length) // Works, but with risk of NPE

Note: you cannot explicitly write String! in your code. It is an internal compiler marker. But understanding its essence is critically important for optimization and performance.

Single Exclamation Mark and Performance: Myths and Reality

Now we move on to the most interesting part — performance. Many developers believe that platform types (and the exclamation mark) are just syntactic sugar for Java compatibility. But in reality, they affect code generation and execution speed.

How does Kotlin handle platform types?

When you work with String!, the Kotlin compiler generates bytecode that does not add null checks at runtime. Unlike nullable types (String?), where each operation can trigger a hidden check, platform types behave like regular Java types — without overhead.

This means that using platform types can be faster than explicitly declaring nullable types. But there is a nuance: you lose safety.

Example: performance of nullable vs platform type

// Java class\npublic class DataProvider {\n    public static String getData() {\n        return "fast";\n    }\n}\n\n// Kotlin: using platform type (implicitly)\nfun usePlatformType(): Int {\n    val data = DataProvider.getData() // String!\n    return data.length // No checks\n}\n\n// Kotlin: explicitly nullable\nfun useNullable(): Int? {\n    val data: String? = DataProvider.getData()\n    return data?.length // Null check at runtime\n}

In the first case (usePlatformType), the bytecode will be almost identical to Java code — no additional instructions. In the second (useNullable), the compiler will insert a null check and a conditional branch. At the micro level, this can