For years, Crashlytics by Fabric was the gold standard for mobile crash reporting. It was fast, reliable, deeply integrated with Android tooling, and free. Teams adopted it without hesitation, and it became load-bearing infrastructure for mobile development at companies of every size.

Then Google acquired Fabric.

The migration from Fabric Crashlytics to Firebase Crashlytics was manageable for many teams, but it immediately raised a set of questions we could not get clear answers to. Firebase tools, as a rule, depend on Google Play Services — a hard requirement that excludes Huawei devices running HMS (Huawei Mobile Services) and the Chinese Android ecosystem more broadly, where GMS is not available. China represented a significant portion of our user base, and the prospect of running two parallel crash reporting systems — one for GMS markets, one for HMS — was operationally unappealing.

Beyond the immediate practicalities, the acquisition surfaced a deeper concern: our crash reporting infrastructure was entirely controlled by a third party whose roadmap we could not influence and whose business decisions could affect our operations at any time. We had already lived through one such decision.

These concerns, taken together, pointed toward building our own crash reporting system.

The Strategic Case for Ownership

The defensive argument for building in-house crash reporting — vendor independence, market coverage — was sufficient on its own. But the more compelling argument was what becomes possible when you own the data pipeline end to end.

Crash data contains rich, structured information: the file, the class, the line number, the thread state, the stack at the moment of failure. In our system, we could connect this information directly to our existing infrastructure:

Automated incident response: Every crash has a filename and line number. Our codebase is managed in Git. Using git blame, we can map any crash directly to the commit that introduced the failing code and the team responsible for it. An automated system can open a ticket, notify the relevant team, or even trigger a rollback — without human intervention.

Feature flag integration: Our release process is built around feature flags and A/B tests. A new feature is always behind a flag before it is fully rolled out. When a crash occurs in a flagged feature, we can identify the flag from the source location and automatically disable it, preventing further exposure to the crashing code path. This closes the loop from crash detection to crash mitigation without a human on-call cycle.

Developer attribution and accountability: The git blame pipeline also enables precise attribution. The system can automatically notify the developer whose commit introduced a crash within minutes of the first occurrence in production — far faster than any manual triage process.

ML-assisted root cause analysis: With full ownership of crash data and the infrastructure to process it, training models to identify crash-prone patterns, predict regression risk from code changes, or cluster related crashes by root cause becomes tractable. The vision of receiving a suggested fix within minutes of a crash is not science fiction; it requires data ownership as a prerequisite.

To be fair, some of this is achievable using Firebase Crashlytics data exported to BigQuery. But BigQuery export introduces latency measured in hours, not seconds. For real-time incident response, that latency is disqualifying. And the China market problem remains regardless.

How: The Android Client

The Android client side of a crash reporting system is simpler than the backend. The backend handles the hard problems: deobfuscating stack traces from ProGuard/R8 symbol maps, deduplication, aggregation, alerting, and visualization. The Android client has one job: reliably capture exceptions and ensure they reach the backend.

Registering the Exception Handler

Java and Android provide a standard mechanism for catching unhandled exceptions: Thread.setDefaultUncaughtExceptionHandler. This handler is invoked for any exception that propagates to the top of a thread’s call stack without being caught:

val defaultHandler = Thread.getDefaultUncaughtExceptionHandler()

Thread.setDefaultUncaughtExceptionHandler { thread, throwable ->
    try {
        crashLogger.log(thread, throwable)
    } finally {
        defaultHandler.uncaughtHandler(thread, throwable)
    }
}

Two details here are critical for correctness:

First, save the existing default handler before replacing it, and call it in a finally block after your own handler runs. The default handler is responsible for terminating the process, producing the system crash dialog, and notifying the Android runtime. If you replace it without delegating to it, the process will not terminate normally, producing strange behavior and potentially causing subsequent launches to appear in a non-crashed state.

Second, the finally block ensures the default handler is called even if your own crash logging throws an exception — which is possible if the application is in a severely degraded state.

This setup code can be placed in Application#onCreate(). For applications where early-lifecycle crashes are a concern, a ContentProvider initialized before Application#onCreate() can be used to register the handler even earlier in the process startup sequence.

Why You Cannot Make a Network Call Immediately

The instinct when catching a crash is to send it to the backend immediately. This does not work reliably, for three reasons:

1. The process is about to die. The uncaught exception handler runs immediately before process termination. Any async work started in the handler — a network request, for example — will be killed before it completes.
2. The main thread may be unresponsive. If the crash occurred on the main thread, the UI event loop is no longer running. Network libraries that dispatch callbacks to the main thread will silently fail.
3. The heap may be exhausted. Some crashes are caused by OutOfMemoryError. Attempting to allocate new objects for a network request in this state will fail immediately.

The correct pattern is a two-phase approach: save the crash locally during the crash handler, then send it to the backend on the next application launch, after the process has restarted cleanly and the network stack is fully operational.

interface CrashLogger {
    fun log(thread: Thread, throwable: Throwable)
}

class FileCrashLogger : CrashLogger { ... }
class SqliteCrashLogger : CrashLogger { ... }

FileCrashLogger writes the crash as plain text to a file. It has minimal dependencies and is unlikely to fail during a crash — even if the application heap is under pressure, writing a small file to disk does not require significant allocation.

SqliteCrashLogger writes to a SQLite database. This enables structured queries on crash history (useful if you want to deduplicate on the client), atomic writes, and easier enumeration of pending crashes. The trade-off is that SQLite itself is a complex system; if the crash was caused by database corruption or if SQLite’s own thread pool is in a bad state, the logger may fail. For maximum reliability in crash scenarios, file storage is safer.

Capturing the Stack Trace

Converting a Throwable to a string for storage is straightforward:

val sw = StringWriter()
throwable.printStackTrace(PrintWriter(sw))
val str = sw.toString()

For comprehensive diagnostics, capturing the state of all threads at the moment of the crash can be invaluable — particularly for diagnosing deadlocks, thread contention, or crashes caused by interactions between background work and the main thread:

val stackTraces = mutableMapOf<String, String>()

Thread.getAllStackTraces().forEach { (thread, stackTrace) ->
    val stringBuilder = StringBuilder(thread.name)

    stackTrace.forEach { element ->
        stringBuilder
            .append("\n\tat ")
            .append(element.className)
            .append('.')
            .append(element.methodName)
            .append('(')
            .append(element.fileName)
            .append(':')
            .append(element.lineNumber)
            .append(')')
    }

    stackTraces[thread.name] = stringBuilder.toString()
}

For use cases where only the crash origin matters — for example, to look up the associated feature flag or git blame entry — the minimal form is sufficient:

throwable.stackTrace?.firstOrNull()?.let { crash ->
    crash.fileName // sample.kt
    crash.lineNumber // 42
    crash.className // Sample
}

One production edge case worth handling: Throwable#getStackTrace() can return an empty array. This occurs when the Throwable was constructed with writableStackTrace = false — a legitimate optimization sometimes used for exception types where stack traces are never needed (certain ArithmeticException subclasses, for example). A null or empty check guards against firstOrNull() returning null in this case.

What This System Does Not Cover

This article covers the Android client component. A production-ready system requires substantially more:

• Symbol map management: ProGuard and R8 obfuscate class and method names in release builds. The backend must maintain a mapping from obfuscated names back to source symbols, keyed by build version, and apply it to every incoming crash report.
• Multi-process apps: Android applications can run in multiple processes (services, remote processes, etc.). The uncaught exception handler must be registered separately in each process. A ContentProvider that performs registration in its onCreate is a clean way to ensure this happens automatically.
• JNI crashes: Native crashes in JNI code are not captured by Thread.setDefaultUncaughtExceptionHandler. Native crash handling requires separate mechanisms (signal handlers, breakpad, or Firebase Crashlytics’s native SDK).
• ANR detection: Application Not Responding errors are a distinct failure mode from exceptions. Detecting them requires a separate watchdog mechanism — typically a background thread that monitors main thread responsiveness.

The client-side implementation described here is intentionally minimal — a foundation on which a full crash reporting pipeline can be built. The interesting and difficult problems live in the backend and the integration layer, but they all depend on this foundation being correct and reliable.

NOTE: This code is a sample. If you want to make a production-ready system, there are many additional considerations beyond what is covered here.

Story

Engineering culture at scale is difficult to build and even harder to maintain. In our company, we made a deliberate decision to enforce code coverage as a merge requirement — a hard gate on the CI pipeline that prevented branches from being merged unless they met a minimum threshold. We chose 80%: every new or modified class had to be covered by unit tests to at least that level.

There are many debates about what the right coverage threshold is, whether coverage is a useful metric at all, and how to avoid gaming it. This article is not about that.

The policy had real effects. Teams began writing more testable code. Architecture improved — highly coupled, untestable code tends to resist coverage requirements in ways that become impossible to ignore. App stability measurably increased. The discipline around testing became part of how we worked, not an afterthought.

But we quickly discovered a class of code that was untestable not through neglect or poor design, but by its nature:

• Legacy code with deeply tangled dependencies, thousands of lines that would require months of refactoring before tests could be written — refactoring that the business would not prioritize because “it works”
• Auto-generated code — output from annotation processors, AIDL interface bindings, generated Room DAOs, Dagger components — code that is correct by construction and pointless to re-test
• Delegating code that exists only to forward calls and has no logic to verify

These classes needed to be excluded from coverage calculations so that teams could meet the threshold on the code they actually owned and controlled.

Then we migrated from Java to Kotlin, and the problem became significantly more complex.

The Kotlin Bytecode Problem

JaCoCo operates at the bytecode level. It instruments compiled .class files by injecting probes that track which lines and branches have been executed. This works reliably for Java code, where the relationship between source lines and bytecode is relatively straightforward.

Kotlin is different. The language is designed to eliminate boilerplate, and it achieves this by having the compiler generate significant amounts of bytecode from compact source constructs. A few examples:

• A simple data class with three fields generates equals, hashCode, toString, copy, and three componentN functions — all as fully-realized bytecode methods that JaCoCo counts independently.
• A safe call s?.foo() compiles to a null check (if/else branch in bytecode), even though there is no explicit conditional in the source.
• A lateinit var field access generates a null check that appears as an uncovered branch if the test path never triggers the uninitialized case.
• Companion objects, object declarations, and sealed class subclasses all generate additional bytecode scaffolding.

The result: coverage numbers for Kotlin projects are systematically lower than the source code suggests. A data class that any developer would consider fully tested — constructors called, methods invoked — shows gaps because JaCoCo is counting generated bytecode that has no corresponding source line for tests to exercise. For a large Kotlin project, this distortion can move the effective coverage percentage by 5–15 points.

When coverage is a KPI, or when it gates merges in an automated pipeline, that distortion has real consequences.

Approaches We Explored

1. Custom Gradle task with filename filters

The standard approach, and the first thing any team discovers when searching for this problem, is to define an exclusion list in the JacocoReport Gradle task:

task jacocoTestReport(type: JacocoReport, dependsOn: [...]) {
    // filter rules
    def fileFilter = [
        '**/R.class',
        '**/R$*.class',
    ]

    def debugTree = fileTree(
        dir: "${buildDir}/intermediates/classes/debug",
        excludes: fileFilter // <-- exclude listed classes
    )

    classDirectories = files([debugTree])

    // some code...
}

This works for known, predictable class names — R.class, generated Dagger classes, known suffixes. The exclusion list lives in one place and is easy to audit.

The problem is that glob patterns applied to class names are brittle. In one memorable incident, a rule intended to exclude R.class and its nested classes (**/R$*.class) was written as **/R*.class — a subtle difference that caused JaCoCo to silently exclude every class whose name began with “R”. This went unnoticed for weeks, producing a coverage report that was technically generated but factually wrong.

Glob-based exclusion also creates an organizational problem: the list of excluded classes is in the build configuration, disconnected from the source files. There is no mechanism to detect when an exclusion entry becomes stale because the class it targeted was renamed or deleted. The list tends to accumulate cruft over time.

2. Annotation processor

A colleague proposed a more elegant solution: create a @NoCoverage annotation and an annotation processor that reads it at compile time, collects all annotated class names, and writes them to a file. The Gradle task would then read that file as its exclusion list instead of a hardcoded array.

This was genuinely clever. The exclusion list becomes self-maintaining — developers annotate the classes they want excluded, and the configuration stays in sync with the source automatically.

The practical limitation is a phase mismatch. Annotation processors run during Kotlin/Java compilation. The JacocoReport Gradle task runs after compilation, during test execution and report generation. Coordinating the output of the annotation processor as an input to the Gradle task requires explicit task dependency wiring that is fragile across Gradle versions, build types, and module boundaries. In a multi-module project, the complexity becomes significant.

APT was designed to generate code, not to produce configuration consumed by external Gradle tasks. Using it for this purpose works, but it fights against the tool’s intended grain.

3. Forked Kotlin compiler

We learned that the JaCoCo team had added a special filter for Lombok — a Java code generation library — that suppressed coverage counting for methods annotated with @Generated. This made perfect sense: Lombok-generated code, like Kotlin-generated code, should not require test coverage.

A colleague proposed the obvious extension: if JaCoCo respects @Generated on methods, and if the Kotlin compiler generated that annotation on its auto-generated methods (data class helpers, etc.), the problem would be solved at the source.

The Kotlin compiler does not do this. So the colleague forked the Kotlin compiler and modified it to add @Generated annotations to every compiler-generated method.

This is remarkable. Forking a programming language’s compiler to solve a tooling problem is a drastic step, and it demonstrates both the severity of the issue and the depth of knowledge required to address it at that level. The forked compiler was never used in production — the maintenance burden would be untenable — but the experiment proved the concept worked.

Subsequently, JaCoCo added its own filter for @kotlin.Metadata, which covers some Kotlin-generated constructs. But this did not fully solve the problem for all generated code in Kotlin projects.

Solution: Annotation + Kotlin typealias

While reading JaCoCo’s source code to understand what filters were available, I discovered something significant. The AnnotationGeneratedFilter — the filter originally added for Lombok support — had been changed from an exact name match to a substring match. Specifically, the annotation’s simple class name only needs to contain the word “Generated”.

This means that any annotation whose class name contains “Generated” will cause JaCoCo to exclude the annotated element from coverage analysis. We do not need to use javax.annotation.Generated. We can create our own annotation with an appropriate name:

@Retention(AnnotationRetention.BINARY)
annotation class NoCoverageGenerated

typealias NoCoverage = NoCoverageGenerated

// or just

typealias NoCoverage = Generated // from javax.annotations package

The typealias is a small but meaningful touch. At the bytecode level, NoCoverage is transparent — the JVM sees NoCoverageGenerated, which contains “Generated” and triggers the JaCoCo filter. At the source level, @NoCoverage is readable and clearly expresses the developer’s intent: this class is intentionally excluded from coverage.

Applying it is simple:

@NoCoverage
data class GeneratedEntity(val id: Int, val name: String)

JaCoCo will skip this class entirely in its coverage calculations.

Pros:

• No build configuration changes
• No code generation
• Exclusion stays co-located with the source it applies to
• Works correctly across modules and build variants

Cons:

• This is a workaround. The JaCoCo wiki explicitly states:

  Remark: A Generated annotation should only be used for code actually generated by compilers or tools, never for manual exclusion.

• The annotation is present in the compiled artifact. In Android projects using ProGuard, R8, or DexGuard for release builds, annotations with BINARY retention are stripped during optimization, so there is no production impact. For projects that do not use code shrinking, the annotation remains in the release artifact but has no runtime effect.

In practice, the constraint from the JaCoCo wiki reflects an ideal, not a reality. Large Kotlin projects contain genuinely untestable code — legacy code under business constraints, transitional code mid-refactor, structural code that is correct by construction. Teams need a practical mechanism to handle these cases. The annotation approach provides that mechanism with minimal overhead and maximal clarity at the point of use.

This article was originally posted on Medium.

Kotlin’s data class toString is generated automatically to include every property defined in the primary constructor. This is convenient for debugging but problematic when some of those properties contain sensitive data — passwords, tokens, PII — that must not appear in logs, crash reports, or analytics pipelines.

There is no built-in Kotlin mechanism to exclude a specific field from the generated toString while keeping it in equals, hashCode, and copy. The language does not (yet) offer an annotation equivalent to @Transient for serialization. The approaches below represent the practical trade-offs available in pure Kotlin, each with distinct implications for class semantics, mutability, and maintainability.

1. Override toString() yourself

The most straightforward approach is to manually override toString in the data class body:

data class Data(
    val login: String,
    val password: String
) {
    override fun toString() = ""
}

What this solves: Prevents password from appearing in log output immediately and without adding any new types or indirection.

What this breaks: You have opted out of the entire auto-generated toString. If you want other properties to appear — login, for example — you must now construct the string manually. Every time you add a new property to the class, you must remember to update the override. If you forget, the new property will silently never appear in logs, which is often exactly the wrong behavior. The maintenance burden grows proportionally with the class size.

It is also worth noting that overriding toString only affects logging output. The password field is still fully included in equals, hashCode, copy, and destructuring (componentN). Those semantics remain intact — which is usually what you want, but is worth understanding clearly.

When to use this: Acceptable for small, stable classes that are unlikely to grow, where the only goal is to suppress all output in logs entirely. For anything more nuanced, the maintenance cost is not worth it.

2. Define the property outside the primary constructor

Kotlin data class semantics only apply to properties declared in the primary constructor. Properties declared in the class body are excluded from toString, equals, hashCode, copy, and all componentN functions:

data class Data(
    val login: String
) {
    var password: String
}

// Usage - instantiate and set
val data = Data("login")
data.password = "password"

What this solves: password is completely invisible to all auto-generated data class functions. It will never appear in toString, and it does not participate in equality comparisons or copy().

What this breaks: The exclusion from equals and hashCode changes the object’s identity semantics in a fundamental way. Two Data instances with the same login but different passwords are considered equal by the data class. copy() will produce a new instance without password copied — setting it to an uninitialized state. If Data objects are used as keys in maps or stored in sets, or if copy() is used to produce modified versions, these behaviors may produce subtle bugs.

There is also a forced mutability problem: defining a field in the class body requires it to be var (unless it has a default value). This breaks the immutability of the data class, which is often a core reason for choosing data classes in the first place. Initialization requires a two-step process — construct then set — which makes the class impossible to use in most functional pipelines.

When to use this: When the property genuinely has no place in equality comparisons or copying — for example, a lazily-computed cache value or a transient UI handle. It is a poor fit for actual data fields like passwords.

3. Use a wrapper class

A more principled approach is to wrap the sensitive value in a type whose toString returns an empty string or a redaction marker:

// Wrapper
class Secret<T>(val data: T) {
    override fun toString() = ""
}

data class Data(
    val login: String,
    val password: Secret<String>
)

// Usage - create / read
val data = Data("login", Secret("password"))
data.password.data

What this solves: password participates fully in all data class semantics — it is included in equals, hashCode, copy, and destructuring. The only thing suppressed is the value in toString. The original data class structure is preserved, and you get correct copy() behavior.

There is an additional, underappreciated benefit: the type system now makes the sensitivity of this field explicit. When a developer reads the class definition, Secret<String> signals immediately that this field requires careful handling. It serves as inline documentation that persists through refactors. Code review tools and static analysis can potentially flag any access to .data on a Secret instance to ensure it is not being logged unsafely.

What this breaks: Accessing the underlying value requires an extra .data dereference. This creates a small but consistent friction at every use site. Some developers view this as a drawback; others view it as a feature — friction that makes accidental logging slightly harder. The type is also not directly comparable to a plain String, which may complicate integration with serialization libraries or frameworks that expect a specific type.

A production-quality Secret<T> implementation should also override equals and hashCode to delegate to the wrapped value, ensuring that Data("login", Secret("a")) != Data("login", Secret("b")) works as expected.

When to use this: The strongest of the manual options. The type-level signal, correct data class semantics, and composability make this a good pattern for codebases that need systematic protection without a compiler plugin.

4. Do not use data classes

Sometimes the right answer is to step back and ask whether a data class was the appropriate choice at all:

class Data(
    val login: String,
    val password: String
)

A regular class gives you complete control over toString, equals, hashCode, and copy (or the absence of copy). There is no auto-generated behavior to work around.

When to use this: When the class does not actually need the semantics of a data class — no structural equality comparisons, no destructuring, no copy() calls. If the class is used only as a container passed through a pipeline and never compared or copied, the data class overhead (and the toString problem) may be unnecessary. Choosing a regular class in this case is not a workaround — it is the appropriate design decision.

The Underlying Problem with All Four Approaches

Each of the options above requires the developer to actively remember to protect every sensitive field, in every class, at every point in the class’s lifetime. They are all opt-in: the default behavior is to expose everything.

This creates a systematic risk. As classes evolve — new fields added, existing fields renamed — the protection must be consciously re-applied. A developer unfamiliar with the codebase’s conventions, or working under time pressure, will produce a class that leaks by default.

The Sekret compiler plugin addresses this at the root: protection is declared once per field with an annotation, and the compiler enforces it permanently. The annotation travels with the field through refactors, class renames, and codebase migrations. No manual toString override to maintain, no wrapper type to thread through the codebase — just a single annotation that expresses intent and delegates enforcement to the compiler.

One of Kotlin’s most appreciated features is the data class. With a single keyword, the compiler automatically generates equals, hashCode, copy, componentN, and toString — eliminating an entire category of boilerplate that Java developers had to write and maintain by hand. For domain objects, value types, and state containers, data classes are the obvious choice.

The toString function, in particular, is invaluable for debugging. When you log a data class instance, you get a complete, readable snapshot of its state: every field name and value, formatted cleanly. This is exactly what you want during development.

In production, it becomes a liability.

Consider a typical MVI (Model-View-Intent) architecture, where a view receives a single state object containing everything it needs to render:

data class ViewState(
    val username: String,
    val password: String,
    val isButtonEnabled: Boolean
)

// PS: never keep passwords in String

Adding observability to this pattern is natural and encouraged:

fun render(viewState: ViewState) {
    logger.info("render $viewState")
    ...
}

When logger.info calls viewState.toString(), it produces something like:

ViewState(username=james.bond, password=123456, isButtonEnabled=true)

That string now flows wherever your logger sends data — logcat, crash reporters, analytics SDKs, remote log aggregation services, third-party monitoring platforms. Every system that receives your logs now receives your users’ passwords.

This is not a hypothetical risk. It is a concrete, reproducible data pipeline from your application to third-party servers, with your users’ sensitive data flowing through it on every state change.

The Scope of the Problem

The data leakage vector extends well beyond Android’s MVI pattern. Any architecture that uses data classes as data containers and logs those containers is affected:

• Crash reporters (Crashlytics, Sentry, Bugsnag) allow you to attach context objects to crash reports. If that context is a data class, its full contents — including sensitive fields — appear in the crash report.
• Analytics pipelines frequently serialize events and their associated state for processing. Data classes are natural event payloads.
• Microservice architectures often log all incoming and outgoing messages for observability. If your message types are data classes, every request and response is fully exposed in your log infrastructure.
• Repository pattern with sealed class results: Result.Success(data = userProfile) — logging the result logs the entire user profile.
• State machines logging every state transition: each logged state includes every field.

The common thread: modern logging practices encourage comprehensive observability. Data classes make it trivial to log anything. The intersection of the two creates a systematic PII (Personally Identifiable Information) exfiltration risk.

Regulatory Consequences

This is not just a best-practice concern. Under GDPR (General Data Protection Regulation) in the European Union, logging personal data — names, email addresses, passwords, health information, financial data — without a legitimate legal basis and appropriate technical controls can result in fines of up to €20 million or 4% of global annual revenue, whichever is higher. CCPA (California Consumer Privacy Act) carries similar obligations in the US. PCI DSS requirements explicitly prohibit logging cardholder data.

The challenge is that these leaks are silent. There is no exception, no warning, no test failure. The data simply flows into log storage, where it may sit unnoticed for months or years.

Existing Workarounds and Their Limitations

There are several manual approaches to excluding sensitive fields from toString. Each requires the developer to actively remember to protect every sensitive field, in every class, every time a class is modified.

Overriding toString entirely is the simplest approach but introduces a maintenance burden: every new property addition requires manually updating the override. Miss one update after a refactor and you have reintroduced the leak.

Wrapper types (Secret<T>) are more principled but require changing the field type, which affects the API surface, copy() calls, and any serialization configuration.

Defining fields outside the primary constructor removes them from all data class semantics, but forces mutability and changes equality semantics — two Data instances with different passwords compare as equal.

All of these approaches share a fundamental weakness: they are opt-in. The default behavior leaks. A developer who does not know about the risk, or forgets to apply the protection to a new field, produces a vulnerable class with no warning from the compiler.

Solution: A Compiler Plugin

Sekret is a Kotlin compiler plugin that modifies the generated toString bytecode for annotated fields during compilation. Instead of writing manual overrides or restructuring your data classes, you annotate individual sensitive fields with @Secret:

data class Data(
    val username: String,
    @Secret val password: String
)

print(Data("james.bond", "123456"))

// prints out
// Data(username=james.bond, password=■■■)

The password field is replaced with a redaction marker (■■■) in the output. Every other field continues to appear normally. The data class retains all its semantic properties — equals, hashCode, copy, and componentN all include the password field as expected. Only toString is modified, and only for annotated fields.

How the Compiler Plugin Works

Building a Kotlin compiler plugin requires working at a level most Kotlin developers never encounter. The Kotlin compilation pipeline processes source code through several stages: parsing into a PSI (Program Structure Interface) tree, type-checking and resolution, translation to an IR (Intermediate Representation) tree, and finally code generation to JVM bytecode.

Sekret hooks into the IR stage. When the compiler generates the IR for a data class toString method, the plugin inspects the fields included in the generated implementation, identifies those annotated with @Secret, and rewrites the IR nodes responsible for appending those field values — replacing the value reference with a constant redaction string.

The result is identical to what you would get if you had hand-written toString to exclude the field, but it is generated automatically, stays in sync with the class definition as it evolves, and requires zero manual intervention after the initial annotation.

Critically, this is a compile-time transformation with no runtime overhead. The generated bytecode is as efficient as a hand-written toString. There is no reflection, no proxy, no wrapper object allocated per invocation.

Design Philosophy

The @Secret annotation approach is deliberately declarative and self-documenting. When a code reviewer sees a field annotated with @Secret, the intent is immediately clear: this field contains sensitive data that must not appear in logs. The annotation serves double duty as both a functional directive and inline documentation.

This is the same philosophy behind @Transient for serialization — you annotate the field to opt out of a default behavior, rather than restructuring the class. Kotlin’s standard library already uses this pattern for serialization; Sekret brings it to toString.

The protection is also future-proof. Once a field is annotated, it remains protected regardless of how the surrounding class evolves. New fields added to the class appear in toString as normal. The annotated field never does.

More info on GitHub: https://github.com/aafanasev/sekret

Perhaps JetBrains will eventually offer an out-of-box solution similar to the @Transient annotation for serialization — a standard way to exclude fields from the compiler-generated toString. Until then, Sekret fills that gap.

This article was originally posted on Medium.

However, there is a subtle but serious trap hiding in that combination — one that silently violates Kotlin’s type safety guarantees and can cause crashes that are difficult to reproduce and frustrating to diagnose.

The Problem: GSON Breaks Kotlin’s Null Safety Contract

Kotlin’s null safety is one of its most valuable features. When you declare a property as non-nullable (val id: Int), the compiler enforces at every call site that this value cannot be null. The type system becomes a correctness guarantee you can rely on throughout your codebase.

GSON’s default deserialization strategy, however, does not understand Kotlin’s nullability. It uses ReflectiveTypeAdapterFactory, which bypasses normal object construction entirely. Instead of calling your Kotlin constructor — which enforces null checks — GSON uses sun.misc.Unsafe.allocateInstance() to create objects directly from bytecode, then sets fields via reflection.

The practical consequence: GSON will happily deserialize null into a non-nullable Kotlin field, and your code will not know until something dereferences it:

data class Entity(val id: Int)
val json = """{ "id": null }"""
val entity = gson.fromJson(json, Entity::class.java)
entity.id // <- Throws NPE

What makes this especially dangerous is where the exception surfaces. The failure does not happen at the parsing boundary — where it would be easy to catch, log, and handle — but somewhere deep in business logic, minutes or hours later, in code that has every reason to trust that entity.id is safe to use. This produces NullPointerExceptions in code that looks correct, coming from a source that the developer never suspects.

This is not a theoretical edge case. Malformed API responses, backend bugs, schema evolution, and network corruption all produce null fields from time to time. When they do, a reflection-based deserializer will pass the corruption silently downstream.

Why There Was No Easy Fix

The root cause lies in a fundamental incompatibility between the JVM type system and Kotlin’s nullability model.

Kotlin’s non-nullability is a compile-time construct. At the bytecode level — the level GSON operates at — a val id: Int is indistinguishable from a var id: Int?. Nullability annotations are present in the Kotlin metadata attached to the class, but GSON’s reflection-based adapter does not read them. It sees a plain Java int field and writes whatever value it finds in the JSON, including null (which becomes 0 for primitives, or an actual null reference for objects).

The correct fix requires generating a custom type adapter for each data class — one that calls the actual Kotlin constructor, which performs null checks at instantiation time. Writing these by hand is tedious and error-prone. Every time a class changes, the adapter must be updated. Forgetting to update it reintroduces the bug silently.

The Java Precedent

This problem has a well-established precedent in Java. The AutoValue library generates immutable value classes from abstract definitions, and the companion AutoGson extension generates matching GSON type adapters automatically. Java teams used this combination to get safe, efficient GSON deserialization without boilerplate.

When Kotlin was introduced and teams began migrating their model classes to data classes, the AutoValue+AutoGson combination no longer applied — data classes have their own, distinct mechanism. At the time I built KSON, there was no equivalent library for Kotlin. KSON was written to fill that gap.

How KSON Works

KSON uses Kotlin’s annotation processing (kapt) to generate type adapters at compile time. Annotate a data class with @Kson:

@Kson
data class Entity(val id: Int)

During compilation, the annotation processor reads the class’s constructor parameters, their types, and their names, then generates a concrete TypeAdapter<Entity> that calls the Kotlin constructor directly. If a required field is null in the JSON, the adapter throws a JsonParseException at the parsing boundary — exactly where the error belongs.

There is no runtime reflection, no dynamic proxy, and no startup cost. The generated adapter is a plain Kotlin class that GSON uses like any other hand-written adapter. The correctness guarantee is identical to writing the adapter by hand, and it stays in sync with your model class automatically.

For larger projects with many model classes, @KsonFactory generates a TypeAdapterFactory that registers all generated adapters in one call:

@KsonFactory
object FactoryProvider {
    get() = KsonFactoryProvider() // generated class
}

val gson = GsonBuilder()
    .registerTypeAdapterFactory(FactoryProvider.get())
    .create()

This keeps the GSON configuration clean regardless of how many model classes the project has.

Ergonomics and Adoption

The design intentionally keeps the API surface minimal. Adding KSON to an existing class requires one annotation. Removing it requires deleting one line. There is no configuration file, no code generator to run manually, and no interface to implement. If you decide KSON is not right for your project, the removal is surgical.

This matters in the real world. Libraries that require significant adoption effort see slow uptake and are often abandoned midway through migration. A library that can be incrementally adopted — one class at a time, with instant rollback — is far more likely to be used consistently.

Beyond convenience, the performance argument is meaningful at scale. Reflection-based deserialization is measurably slower than custom type adapters. On mobile devices where CPU resources are limited and startup time is user-visible, the difference adds up across the hundreds of API calls a typical app makes per session.

Impact

GSON remains one of the most widely used JSON libraries in Android development. The null safety vulnerability it creates when combined with Kotlin data classes affects any project that has not explicitly written or generated custom type adapters — which is the majority. KSON provides the missing piece: a zero-configuration, compile-time solution that restores the null safety guarantees Kotlin developers expect and makes reflection-based deserialization of Kotlin classes safe by default.

More info on GitHub: https://github.com/aafanasev/kson

This article was originally posted on Medium.