Kotlin Language Features, Differences from Java, and Their Practical Application in a Mobile Cash Register App

We first classify mobile applications into four major categories: React/Flutter apps, pure Web apps, native apps, and hybrid apps, and further describe mixed‑view patterns such as multi‑view, single‑view, and Web‑centric hybrids.

The previous H5 cash‑register module suffered from long first‑screen load times, awkward popup animations, a lengthy technology stack involving JDWebView, and memory‑related black‑screen issues on low‑end devices.

To eliminate the WebView bottleneck, the cash‑register homepage was rewritten as a pure native page, and the team chose Kotlin as the future‑proof Android language backed by Google.

Understanding Kotlin

Kotlin is a modern compiled, strong‑typed, static language that emerged in 2011 and received official Google support in 2017. Compared with Java, Kotlin offers stronger type inference, functional programming support, and a richer type system.

Kotlin’s language features are grouped into general, procedural, object‑oriented, and functional categories. Examples include variables, scopes, control flow, classes, inheritance, higher‑order functions, lambdas, monads, and immutability.

Kotlin vs. Java Feature Differences

Kotlin introduces data classes, sealed classes, destructuring, infix notation, operator overloading, default parameters, null‑safety, and removes checked exceptions, among other enhancements.

Key functional differences include stronger support for immutability, higher‑order functions, and concise syntax for lambda expressions.

Drawbacks of Kotlin

Multidimensional arrays require nested constructors, making code more verbose than Java.

Some Java interfaces cannot be directly implemented due to overload resolution conflicts.

Absence of checked exceptions can lead to unhandled runtime errors.

Kotlin in the Cash Register Project

Since version V9.2.2, the Android cash‑register module has been developed primarily in Kotlin, with a mixed Java‑Kotlin approach for stability.

Interoperability

Kotlin can call Java code using property‑style accessors, and Java can call Kotlin functions via @JvmOverloads and @JvmStatic annotations.

public final class User {
  public String getName() { /* … */ }
  public boolean isActive() { /* … */ }
  public void setName(String name) { /* … */ }
}
val name = user.name // Invokes getName()
val active = user.active // Invokes isActive()
user.name = "Bob" // Invokes setName(String)

Example of @JvmOverloads:

@JvmOverloads
fun setText(textPair: TriggerTextView, moneyFlag: String = "") {
    setText(textPair, moneyFlag, true)
}

Example of @JvmStatic:

object Updater {
    private var tempSourceList: ArrayList<Entity>? = null
    @JvmStatic
    fun of(block: () -> ArrayList<Entity>): Updater {
        onDestroy()
        tempSourceList = block()
        return this
    }
}

Null‑Safety Practices

All response entities implement an ICheckNull interface to initialize nullable fields, preventing NullPointerExceptions.

public class Response extends BaseEntity implements ICheckNull {
    public List<Plan> list;
    public List<Entity> couponList;
    public List<Entity> cantUseCouponList;
    public Entity selectedCoupon;
    @Override
    public void checkNullObjAndInit() {
        BeanValidator.checkNullList(list);
        BeanValidator.checkNullList(couponList);
        BeanValidator.checkNullList(cantCouponList);
        checkSelectedCoupon();
    }
    private void checkSelectedCoupon() {
        if (selectedCoupon == null) {
            selectedCoupon = new CouponEntity();
        }
        selectedCoupon.checkNullObjAndInit();
    }
}

Kotlin’s platform types are treated as nullable on the Kotlin side, and explicit null checks are added when calling Java APIs.

val payEntity: PayEntity? = Manager.getInstance().createPayEntity(payment)

Additional Kotlin features such as immutable variables (val), property accessors, and Elvis operator further reduce boilerplate null checks.

val currentPlan: String? = defaultCard?.recommendId ?: DEFAULT_PLAN
val activity = (this.activity as? PayActivity) ?: return

Encountered Issues

Fastjson deserialization of Kotlin numeric types resulted in null values; switched to String fields.

Platform compilation failures resolved by introducing intermediate variables.

Uncaught NumberFormatException caused crashes; identified missing exception handling in Kotlin’s toFloat implementation.

Example of the crash:

---java.lang.NumberFormatException: empty String
    at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1842)
    at sun.misc.FloatingDecimal.parseFloat(FloatingDecimal.java:122)
    at java.lang.Float.parseFloat(Float.java:451)

Kotlin’s toFloat delegates to Java’s Float.parseFloat, which throws NumberFormatException for empty strings.

Conclusion

Kotlin is a modern compiled, strong‑typed, static language that aligns with current multi‑paradigm trends. Its richer functional features and built‑in best practices make it a superior choice over Java for Android development. After migrating the cash‑register to native Kotlin, first‑screen load time dropped from ~1180 ms to ~360 ms, a 69.5 % improvement, and no null‑pointer crashes have been observed.