Chapter 1: Kotlin: What and why

Introduction

The chapter introduction characterizes Kotlin as a pragmatic successor to Java and shows how its uses have expanded across applications and platforms.

• Kotlin’s Design and Java Roots: Explain how Kotlin began as a “better Java”: it aims to improve developer ergonomics and prevent common errors while remaining usable wherever Java was used.
  Why it matters: This framing explains both Kotlin’s appeal to Java developers and its emphasis on practical improvements.
• Kotlin’s Uses and Platform Reach: Describe the kinds of applications Kotlin is used for and how its reach has grown beyond its original JVM focus.
  Why it matters: Kotlin is not limited to one application domain or to its original JVM target.

Key terms: better Java, developer ergonomics, concise, safe, pragmatic, JVM, Android, server-side development, targets, cross-platform solutions

1.1 A taste of Kotlin

A small Kotlin example shows how a collection of people can be searched for the oldest person when an age may be missing.

• Oldest Person Example: Trace how the example finds the oldest person when one person's age is unspecified, including the roles of the default null value, maxBy, its lambda, and the Elvis operator.
  Why it matters: This example connects Kotlin's handling of missing values with a collection operation.

Key terms: Person, maxBy, lambda expression, Elvis operator (?:), null

1.2 Kotlin’s primary traits

Introduces Kotlin’s static typing, combination of programming paradigms, and support for asynchronous code.

• Compile-time error detection: Explain what static typing means for when Kotlin can catch many errors.
  Why it matters: This is one of the practical benefits the section associates with Kotlin’s type system.
• Object-oriented and functional combination: Describe the two programming traditions Kotlin combines and the benefit the section attributes to that combination.
  Why it matters: The combination is central to how this section characterizes Kotlin as a multiparadigm language.
• Asynchronous code support: State Kotlin’s stated support for asynchronous code and why the section considers it relevant.
  Why it matters: It identifies another broad capability of Kotlin without requiring its mechanics yet.

Key terms: statically typed, compile time, run time, multiparadigm, object-oriented, functional, abstractions, asynchronous code

1.2.1 Kotlin use cases: Android, server side, anywhere Java runs, and beyond

This section describes Kotlin’s broad range of uses, from Java-compatible environments to cross-platform applications.

• Broad Kotlin use cases: Explain that Kotlin is not limited to one problem domain: it is intended for contexts where Java can be used, including Android applications and server-side code, while improving developer productivity.
  Why it matters: Kotlin’s intended breadth helps explain why it appears in both mobile and backend development.
• Uses beyond Java environments: Describe how Kotlin Multiplatform extends the examples beyond Java-oriented contexts to cross-platform applications for desktop, iOS, and Android, with Kotlin also able to run in the browser.
  Why it matters: Kotlin’s reach is broader than the Android and server-side examples alone suggest.

Key terms: Android, server-side code, Java, Kotlin Multiplatform, cross-platform applications, browser

1.2.2 Static typing makes Kotlin performant, reliable, and maintainable

This section explains how Kotlin combines compile-time type checking with type inference, and what that means for reliability, performance, maintainability, and tooling.

• Compile-time type checking: Explain that Kotlin knows the type of every expression at compile time and uses that information to check whether accessed methods and fields exist and function results have the expected type. Contrast this with dynamic typing, where such references are resolved at run time.
  Why it matters: Compile-time checks can reveal mistakes before the program runs.
• Practical static typing benefits: Describe the performance, reliability, maintainability, and IDE-support benefits the section attributes to static typing, while recognizing the flexibility and shorter code it attributes to dynamic typing.
  Why it matters: The trade-off explains why Kotlin checks types even though dynamic typing can feel more flexible.
• Type inference without declarations: Explain how Kotlin can remain statically typed without requiring an explicit type on every variable, using a variable initialized with an integer as the example.
  Why it matters: Type inference gives Kotlin compile-time type checks without requiring repetitive type declarations.
• Nullable types and reliability: State the safety benefit the section attributes to Kotlin’s nullable types without describing their syntax or detailed rules.
  Why it matters: Nullable types are one example of Kotlin using its type system to catch potential failures early.

Key terms: static typing, dynamically typed, compile time, run time, performance, reliability, maintainability, tool support, dynamic typing, type inference

1.2.3 Combining functional and object-oriented programming makes Kotlin safe and flexible

The section explains the ideas and benefits of functional programming and shows how Kotlin supports them alongside object-oriented programming.

• Functional programming concepts: Describe first-class functions, immutability, and pure functions as the functional-programming ideas introduced here.
  Why it matters: These ideas explain the benefits the section attributes to functional-style code.
• Abstraction and code reuse: Explain how treating functions as values can make code concise and reduce duplication.
  Why it matters: It explains why passing behavior to a function can replace repeated, slightly different code.
• Safety and testability benefits: Explain why immutable data and pure functions help with concurrent code, testing, and reasoning.
  Why it matters: These benefits connect functional-programming choices to practical concerns beyond brevity.
• Kotlin functional support: Describe the language and library features the section identifies as support for functional-style programming, including the message-processing example.
  Why it matters: The features show how Kotlin makes the functional ideas practical to express.
• Object-oriented and functional choice: Explain how Kotlin lets programmers choose between functional and object-oriented approaches rather than requiring a purely functional style.
  Why it matters: It prevents treating the section's functional-programming benefits as rules that forbid other Kotlin styles.

Key terms: first-class functions, immutability, immutable objects, pure functions, side effects, functions as values, abstraction, lambda expressions, safe concurrency, immutable data structures

1.2.4 Concurrent and asynchronous code becomes natural and structured with coroutines

Introduces Kotlin coroutines as a way to write concurrent code that can wait without blocking threads, and illustrates concurrent work and structured cancellation.

• Suspension without thread blocking: Explain that a coroutine can suspend while waiting for a network result and resume later, leaving the underlying thread free to do other work. Describe why this helps code express consecutive requests without blocking a thread.
  Why it matters: This is the central distinction between waiting in a coroutine and blocking an application thread.
• Concurrent loading and cancellation: Describe the section’s example of starting two image loads with async, waiting for both with await, and combining their results. Explain the stated benefit of starting them in the same coroutine scope if one load fails.
  Why it matters: The example shows both concurrent work and a concrete benefit of managing related coroutines together.
• Lightweight concurrent jobs: State the section’s claim that coroutines are lightweight enough to launch very many concurrent jobs without significant performance penalties.
  Why it matters: Lightweight jobs make coroutines useful when an application has many things to do concurrently.

Key terms: coroutines, suspendable computations, suspended, thread, async, await, structured concurrency, coroutine scope, lightweight abstraction, concurrent jobs

1.2.5 Kotlin can be used for any purpose: It’s free, open source, and open to contributions

This section explains that Kotlin is free and open source, describes how developers can contribute, and names open-source IDE options.

• Kotlin’s open-source availability: Explain that Kotlin’s language, compiler, libraries, and tooling are open source and free to use for any purpose under the Apache 2 license.
  Why it matters: You can use Kotlin and its tooling without a licensing fee or a restriction to particular purposes.
• Ways to contribute to Kotlin: Describe how developers can help Kotlin evolve through code contributions, bug reports, feedback, and discussion of potential language features.
  Why it matters: Contributing to Kotlin does not require writing compiler code; reports, feedback, and discussion also count.
• Open-source IDE choices: State which open-source IDEs the section names as fully supported for Kotlin development.
  Why it matters: The section identifies readily available IDE choices for writing Kotlin applications.

Key terms: open source, free to use for any purpose, Apache 2 license, code contributions, bug reports, feedback, Kotlin community, IntelliJ IDEA Community Edition, Android Studio, open source IDEs

1.3 Areas in which Kotlin is often used

Introduces server-side and Android development as two common uses of Kotlin and previews a discussion of why Kotlin fits each.

1.3.1 Powering backends: Server-side development with Kotlin

This section explains why Kotlin suits server-side development and illustrates its use with Spring Boot and Ktor.

• Existing JVM backend integration: Explain why Kotlin fits server-side systems that already use Java and JVM technologies, whether developers are adding a component or migrating an existing service.
  Why it matters: Kotlin can be adopted without treating an established backend as a fresh start.
• Compile-time null protection: Explain how Kotlin’s tracking of null values improves reliability in server-side applications.
  Why it matters: Catching likely null errors before deployment makes backend applications more reliable.
• Spring Boot Kotlin support: Describe how the Spring Boot example shows Kotlin working with an established server-side framework.
  Why it matters: The example makes Kotlin’s fit with established backend frameworks concrete.
• Ktor routing DSL: Describe how Ktor uses a Kotlin DSL to configure HTTP routing and contrast that approach with annotation or XML configuration.
  Why it matters: Ktor illustrates a Kotlin-native approach alongside frameworks such as Spring.

Key terms: server-side programming, JVM, interoperability, Java code, type system, null values, NullPointerException, Spring Boot, first-class support, annotations

1.3.2 Mobile Development: Android is Kotlin first

This section explains why Android is Kotlin first and how Kotlin supports productive, reliable app development without sacrificing compatibility or performance.

• Android Kotlin-first status: Explain what Kotlin first means for Android development and how Google's Android resources reflect that choice.
  Why it matters: The Android ecosystem's Kotlin focus affects the language and resources developers encounter when starting an app.
• Concise Android user interfaces: Describe how Kotlin and Jetpack Compose can make Android UI code simpler, using the expandable-message example.
  Why it matters: The example shows how familiar Kotlin constructs can express UI behavior without a separate UI language.
• Android reliability benefits: Explain the reliability benefit the section associates with adopting Kotlin for Android apps and identify its concrete example.
  Why it matters: Reliability is especially important for mobile apps that must run across many devices.
• Compatibility and performance tradeoffs: Explain why the section says adopting Kotlin need not introduce compatibility or performance disadvantages for Android apps.
  Why it matters: Developers can weigh Kotlin's benefits without assuming an app must become much larger, slower, or limited to the newest Android devices.

Key terms: Kotlin first, Android, Jetpack, Jetpack Compose, if expressions, MessageDetails, NullPointerExceptions, Google Home, Java 8, runtime

1.3.3 Multiplatform: Sharing business logic and minimizing duplicate work on iOS, JVM, JS, and beyond

This section explains where Kotlin code can run and how Kotlin Multiplatform shares code without giving up platform-specific capabilities.

• Kotlin compilation targets: Describe how Kotlin can target JavaScript, native binaries, and WebAssembly in addition to the JVM, and identify where the resulting code can run.
  Why it matters: These targets make sharing Kotlin code across different kinds of applications possible.
• Shared and platform-specific code: Explain how Kotlin Multiplatform combines shared code with platform-specific implementations, and why that helps avoid duplicated work without restricting applications to features common to every platform.
  Why it matters: You can reuse business or validation logic while still using what each target platform offers.

Key terms: JVM, JavaScript, Kotlin/Native, Kotlin/Wasm, WebAssembly, Kotlin Multiplatform, expect/actual, business logic, platform-specific implementation, lowest common denominator

1.4 The philosophy of Kotlin

This section introduces four qualities associated with Kotlin—pragmatism, concision, safety, and interoperability—to be explained in the following sections.

1.4.1 Kotlin is a pragmatic language

This section explains Kotlin’s pragmatism through its real-world focus, cautious feature design, flexibility in programming style, and integrated IDE support.

• Real-world design priorities: Explain what the authors mean by calling Kotlin pragmatic and how real-world use has shaped it.
  Why it matters: This is the section’s central meaning of “pragmatic.”
• Proven and refined features: Describe why Kotlin favors established language ideas and keeps new features experimental before stabilizing them.
  Why it matters: It explains how Kotlin balances familiarity with adding new capabilities.
• Freedom of programming style: Explain how Kotlin lets developers start with familiar techniques and adopt other language features gradually.
  Why it matters: Developers need not change their entire coding style before they can start using Kotlin.
• Tooling as language design: Explain why IDE support is part of Kotlin’s pragmatic design and how it helps developers learn features.
  Why it matters: The IDE is presented not as an afterthought but as part of making Kotlin productive and approachable.

Key terms: pragmatic, real-world problems, developer feedback, proven, experimental state, stable, programming style, paradigm, idiomatic, tooling

1.4.2 Kotlin is concise

This section explains how Kotlin makes code concise without sacrificing readability, and why that matters when developers read and change existing code.

• Readable concision and productivity: Explain why Kotlin values concision in terms of reading existing code, and distinguish clear expression of intent from simply minimizing the number of characters.
  Why it matters: Clearer code takes less time to read and comprehend, not just less time to write.
• Sources of Kotlin concision: Describe how Kotlin removes routine source-code clutter and uses library functions with lambdas to leave task-specific code visible.
  Why it matters: These features reduce repetitive code while keeping the part specific to your task in view.
• Limits on operator syntax: Explain why Kotlin permits overloading only a fixed set of operators rather than letting users invent new ones.
  Why it matters: The operator limit illustrates that readability takes priority over extreme brevity.

Key terms: concise, intent, boilerplate, getters, setters, type inference, standard library, lambdas, anonymous functions, overloading

1.4.3 Kotlin is safe

This section explains how Kotlin reduces common programming errors through JVM and type-system guarantees, nullability checks, and smart casts, while acknowledging that safety involves tradeoffs.

• Safety and productivity tradeoff: Explain what it means for a language to be safe and why greater safety can require more information from the programmer.
  Why it matters: It puts Kotlin’s safety features in perspective: they reduce risks without making errors impossible.
• Layers of Kotlin safety: Describe the safety guarantees Kotlin gets from the JVM and static typing, and the additional safety associated with read-only variables and immutable data classes.
  Why it matters: Kotlin’s safety comes from several layers rather than from one language feature.
• Nullable types and null checks: Explain how Kotlin’s type system aims to prevent NullPointerExceptions and how a nullable type is marked.
  Why it matters: Making possible nulls visible to the compiler helps prevent a common cause of application crashes.
• Type checks and smart casts: Explain how an is check lets Kotlin use a value as the checked type without an explicit cast in the true branch.
  Why it matters: A checked type can be used directly without writing a separate, potentially unsafe cast.

Key terms: safe, compiler, tradeoff, JVM, memory safety, static typing, type safety, val, immutable (data) classes, NullPointerException

1.4.4 Kotlin is interoperable

This section explains how Kotlin and Java code, libraries, and tools work together in a mixed-language project.

• Two-way Java interoperability: Explain how Kotlin can use existing Java APIs and how Java can call Kotlin code, allowing the two languages to coexist in one project.
  Why it matters: You can adopt Kotlin without giving up Java libraries or separating Kotlin and Java code.
• Reuse of Java collections: Describe how Kotlin builds on existing Java library classes, particularly collections, and what that means when passing objects between Kotlin and Java APIs.
  Why it matters: Reusing Java library classes makes calls across the language boundary straightforward.
• Mixed-language tooling support: Describe how compilation and IDE features support projects containing both Java and Kotlin source files.
  Why it matters: A mixed-language project remains workable with familiar compilation and IDE tools.

Key terms: interoperability, Java APIs, Kotlin classes and methods, collections, Java standard library classes, wrap or convert objects, Kotlin tooling, mixed-language projects, Find Usages, IntelliJ IDEA

1.5 Using the Kotlin tools

1.5.1 Setting up and running the Kotlin code

This section explains how to run Kotlin code in a browser or an IDE and how to use the Java-to-Kotlin converter when learning or migrating code.

• Browser and IDE options: Distinguish the quick, installation-free ways to run small Kotlin programs from the fuller development environment provided by IntelliJ IDEA and Android Studio. Describe how to start a Kotlin project in either IDE.
  Why it matters: Choosing the right environment lets you try Kotlin quickly without giving up IDE features when you need them.
• Java-to-Kotlin converter uses: Explain how the converter can help when Kotlin syntax is unfamiliar or when changing an existing Java class, and describe how to invoke it in IntelliJ IDEA.
  Why it matters: The converter lets a Java developer make progress in Kotlin while learning its syntax or updating existing code.

Key terms: Kotlin online playground, IntelliJ IDEA, Android Studio, Kotlin plug-in, Java-to-Kotlin converter, Convert Java File to Kotlin File

1.5.2 Compiling Kotlin code

This section explains Kotlin’s compilation targets, the Kotlin/JVM build process, and the dependencies needed to run compiled code.

• Kotlin compilation targets: Describe the targets Kotlin code can be compiled for, and explain how Android uses compiled JVM bytecode.
  Why it matters: The target determines what form the compiled code takes and where it can run.
• Kotlin JVM compilation process: Trace how Kotlin/JVM source becomes executable code, including the roles of the compiler and JVM.
  Why it matters: It shows how Kotlin source fits into the familiar JVM execution process.
• Libraries and build automation: Explain why a Kotlin/JVM application needs Kotlin libraries and how command-line compilation differs from using Gradle or Maven to include them.
  Why it matters: Class files alone do not supply the Kotlin definitions and APIs an application uses.

Key terms: compiled language, JVM bytecode, Dex bytecode, ART, native targets, JavaScript, .kt, Kotlin compiler, .class files, JVM

1.6 Summary