Java to Kotlin

Preface

Hello, this is Duncan and Nat. As you’re reading this preface, you’re probably trying to decide whether to invest some hours into reading the rest of this book. So let’s cut to the chase:

This book won’t teach you to program computers in Kotlin.

We started writing a book that would, but it soon became clear that Kotlin is a large language, and so the book was going to take longer to write than we wanted. There are also already some great books in that space, and we don’t like competing against great.

We decided instead to make our lives easier by concentrating on teaching Kotlin to Java developers, based on a workshop that we run called Refactoring to Kotlin. This teaches the Kotlin language by converting existing code and is (according to our marketing material) designed for Java teams wanting to leverage their existing knowledge to accelerate their Kotlin adoption.

We started writing that book, but it soon became clear that Kotlin is still a large language, and so we would still be writing for a long time. We also found that motivated and experienced Java developers can pick up most of Kotlin very quickly. It felt patronizing to plow our way through language features that our target readers will probably just appreciate and adopt as soon as they see them. So we abandoned that idea, and as a result:

This book won’t teach you the Kotlin language.

So why should you read it? Because we have written the book we wish was available when we first adopted Kotlin. We are experienced programmers who know Java and the Java ecosystem well. We hope you are too. Like us, you probably have experience in a number of other languages. You’ve learned the basics of Kotlin, and you recognize that to get the best out of the language you will need to design your systems differently. You have found that some things that are cumbersome in Java are much easier in Kotlin, and that some features, such as checked exceptions, are not there at all. You don’t want to end up merely writing Java code in Kotlin syntax.

Perhaps you have skin in the game. Maybe you’re in a technical leadership position, or have successfully convinced your team to adopt Kotlin. You might have spent some political capital to get Kotlin into the project. Now you need to ensure that the transition goes smoothly.

You may be responsible for a Java codebase and want to ensure that introducing Kotlin won’t destabilize its existing, business-critical code. Or you may be starting a Kotlin project from scratch but realize your design instincts turn more readily to Java and objects than to Kotlin and functions.

If this is you, as it was us, then you’ve come to the right place. This book will help you adapt your thinking and designs to take advantage of Kotlin. That’s not enough, though, because you have existing code that you need to maintain and enhance. So we also show how to migrate that code from Java to Kotlin syntax, and from Java to Kotlin thinking, incrementally and safely, using the automated refactoring tools built into the IntelliJ IDE.

How This Book Is Organized

This book is about how to transition from Java to Kotlin, mainly focused on code but touching on projects and organizations. Each chapter addresses an aspect of this transition, looking at some aspect of typical Java projects that can be improved on the journey. They are named in the pattern Java Way to Kotlin Way, where we recommend that you prefer the latter over the former. Maybe Kotlin makes easier an approach that was difficult in Java, or Kotlin discourages an approach that is common in Java to guide design in a direction that is less error-prone, more concise, and more tool-friendly.

We don’t just recommend you adopt the Kotlin way though; the chapters also show how to make the transformation. Not by just rewriting the Java, but by gradually refactoring it to Kotlin it in a way that is safe and allows us to maintain a mixed language codebase.

How Did We Choose the Topics?

We began by analyzing Java and Kotlin developers’ use of their respective languages and conducting interviews to identify areas of difference and confusion. This was backed by a machine learning analysis of 33,459 open source Java and Kotlin codebases. These identified candidates that we labeled in the thing-to-another-thing form before ranking them according to frequency and developer-pain-quotient in order to establish which should make the cut. Finally, we ordered the surviving topics by…

…it’s no good, we can’t lie to you.

The truth is that we started by choosing topics that we wanted to write about, and that we felt would be interesting and informative. Chapter 15, Encapsulated Collections to Type Aliases, Chapter 9, Multi- to Single-Expression Functions, and Chapter 20, Performing I/O to Passing Data are typical of these chapters. We also looked for places where the grain of Kotlin and Java differ significantly, because those were the places where we found we learned most by asking why they were different. This led to chapters like Chapter 4, Optional to Nullable, Chapter 6, Java to Kotlin Collections, and Chapter 8, Static Methods to Top-Level Functions.

As we wrote those chapters, other topics presented themselves and were added to the list. In particular, as we wrote the refactoring steps for a chapter, we often found ourselves making changes to code that we felt deserved their own chapter. Chapter 13, Streams to Iterables to Sequences, Chapter 10, Functions to Extension Functions, and Chapter 11, Methods to Properties are examples of these.

The result of this process is by no means exhaustive. If you have already skimmed the table of contents or index, you will find important topics unaddressed. Take co-routines for example: this paragraph is the only reference to this huge subject, because we have found that they haven’t changed the way that we write server-side code, so we didn’t want to write about them. There are also topics that we would like to have covered if only we had space and time, including: builders, domain-specific languages, reflection, dependency injection frameworks, transactions…the list goes on!

We hope that what we have written about is interesting to you. It is largely a book of tactics rather than strategies, concentrating on the small battles that we can win from our place in the trenches, rather than what might be achieved by directing whole divisions. As larger themes emerge, we will try to connect them, though, and to bring things together in the final chapter, Chapter 23, Continuing the Journey, where we talk about what we have learned during the writing process.

Complexity

How should we judge the internal quality of our software? Assuming that it does what our customers want or need it to do, how can we compare two potential implementations, or decide whether a change makes one better or worse? The answer that your authors choose is complexity. Other things being equal, we favor simple designs that yield predictable behavior.

Of course to some extent, simplicity and complexity are in the eye of the beholder. Your authors do have slightly different personal preferences and so sometimes disagree over whether one implementation or another is better. Where that happens, we sometimes explore the alternatives in the relevant chapter. However, we do both have a shared belief in the power of functional programming to reduce the complexity of our systems, especially when combined with object-oriented (OO) message passing.

Java has been moving in this direction over the years. Scala ran toward functional programming but away from OO. We find that the grain of Kotlin lets us mix functional and object programming in a way that reduces complexity and brings out the best in mere mortal developers.

Perfect Code

On the subject of mere mortals, we should address code quality. It is sorely tempting to aim for perfection when committing code to a book. We know that you will be judging us by the code here, and like many developers, a great deal of our own self-worth is tied up in the quality of the work we produce.

At the same time, we are engineers not artists. Our job is to balance scope, schedule, and cost for our customers. No one but us really cares about the quality of the code except when it affects one of these three higher values.

So in our examples, we have tried to show realistic production code. The starting points are sometimes not as good as we might like; we are, after all, trying to show ways of improving them. Often refactorings will make things worse before they get better, so definitely don’t judge us by code in the middle of a chapter. By the end of a chapter, our aim is to have code that is good enough, but not so perfect that we could be accused of wasting our clients’ money.

That said, we have a policy of applying cost-effective changes to tidy up, even once we have covered the topic we set out to illustrate, and more than once we have invented a topic, and written a chapter just to leave the code in a state that we’re happy with. In the end, we are artists as well as engineers.

Code Formatting

Our code follows (our interpretation of) the standard coding conventions of Java and Kotlin where possible.

The practical line length for printed code samples is much shorter than the 120 characters we usually use in an IDE these days, so we have had to split lines more often than usual to make the code fit in the page width. Our production code might have four or five parameters or arguments on a line; in this book we will often only have one. Through formatting the examples for the page, we have come to like the more vertical style. We find that Kotlin naturally seems to want to take more vertical space than Java, but even Java readability seems improved by shorter lines, more breaks, and more visual alignment. Certainly scrolling sideways is almost as inconvenient in an IDE as in a book, and our pairing sessions are improved by less scrolling and more side-by-side windows. One line per parameter also greatly improves diffs between code versions. We hope that at the very least you don’t find it too painful to read, and if you don’t, then try it for your own code.

We will sometimes hide code that isn’t relevant to the discussion. A line that starts with an ellipsis of three dots indicates that we have omitted some code for clarity or brevity. For example:

fun Money(amount: String, currency: Currency) =
    Money(BigDecimal(amount), currency)

... and other convenience overloads

Conventions Used in This Book

The following typographical conventions are used in this book:

Italic

Indicates new terms, URLs, email addresses, filenames, and file extensions.

Constant width

Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.

Tip

This element signifies a tip or suggestion.

Note

This element signifies a general note.

Warning

This element indicates a warning or caution.

Using Code Examples

Most of the code examples in the book (the ones from the refactoring sections) can be accessed online on GitHub. The reference is immediately after the code, like this:

class TableReaderAcceptanceTests {
    @Test
    fun test() {
    }
}

Example 0.1 [table-reader.1:src/test/java/travelator/tablereader/TableReaderAcceptanceTests.kt] (diff)

If you are reading this on a device, the reference should be a hyperlink to that version of the file on GitHub. On real paper, you can click all you like; nothing will happen, sorry. But if you take the example number, in this case 0.1, and type it into a form on the book’s website, it will show you links that take you to the same place.

In Git, the different code examples (these sometimes span multiple chapters) evolve in separate branches. The steps are tagged—table-reader.1 is the tag in this case. The GitHub link is to code with that tag, so you can view the file shown (src/test/java/travelator/tablereader/TableReaderAcceptanceTests.kt here) and the others in the example at that version. You can also select other tags to see the different versions, and different branches to see different examples. For quicker navigation, you can clone the repository, open it in IntelliJ, and use the Git tool window to switch branches and versions.

Warning

The code examples are not real! The codebase builds and passes its tests, but it is fictional. There are places where the examples don’t join up properly, and others where if you peek behind the curtain you will see us wiggling the levers. We have tried to be honest, but prefer to ship!

If you have a technical question or a problem using the code examples, visit the book’s website or email [e-mail].

This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but generally do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Java to Kotlin by Duncan McGregor and Nat Pryce (O’Reilly). Copyright 2021 Duncan McGregor and Nat Pryce, 978-1-492-08227-9.”

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at [e-mail].

O’Reilly Online Learning

Note

For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed.

Our unique network of experts and innovators share their knowledge and expertise through books, articles, conferences, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, please visit http://oreilly.com.

How to Contact Us

Please address comments and questions concerning this book to the publisher:

• O’Reilly Media, Inc.
• 1005 Gravenstein Highway North
• Sebastopol, CA 95472
• 800-998-9938 (in the United States or Canada)
• 707-829-0515 (international or local)
• 707-829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/java-to-kotlin.

Email [e-mail] to comment or ask technical questions about this book.

For news and information about our books and courses, visit http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://youtube.com/oreillymedia

Acknowledgments

Thank you to Hadi Hariri for suggesting to O’Reilly that we should write a book, and to Zan McQuade for believing him. Thank you to our editor Sarah Grey, who had to live with the consequences, and Kerin Forsyth and Kate Galloway for tidying everything up and actually getting it published.

Many friends and colleagues, and some lovely strangers, reviewed drafts ranging from early and uncoordinated to tantalizingly nearly complete. Thank you to Yana Afanasyeva, Jack Bolles, David Denton, Bruce Eckel, Dmitry Kandalov, Kevin Peel, James Richardson, Ivan Sanchez, Jordan Stewart, Robert Stoll, Christoph Sturm, Łukasz Wycisk, and Daniel Zappold and to our technical reviewers, Uberto Barbini, James Harmon, Mark Maynard, and Augusto Rodriguez. We really appreciate all your suggestions, encouragement, and candor.

Extreme Programming revolutionized the way that write software—we all owe a debt of gratitude to Ward Cunningham and Kent Beck. Thank you also to Martin Fowler, without whom this book might not have been written. In the UK the eXtreme Tuesday Club has been innovating on these ideas since 1999, and has attracted a cabal of developers. We are lucky to have worked with, and learned from, many talented members of this group. If you have a problem, if no one else can help, and if you can find them, maybe you can hire them.

Duncan’s Bit

I don’t think my wife will ever understand what I do for a living, and there’s no chance that she will read the rest of this book, but she will probably get this far. So thank you, Jo McGregor, for putting up with me writing rather than spending time with you, and talking about writing when I was spending time with you. I couldn’t have done it without your support and encouragement. Thank you also to our two wonderful sons, Callum and Alistair, who make us so proud.

Thank you to Vickie Kennish for taking a keen interest in becoming the mother of an author, checking on progress during our COVID lockdown walks. My late father, John, would I’m sure have played it more casual, but be bragging about the book to his friends. Also gone but not forgotten is our beautiful cat Sweet Pea, who kept me company through most of the writing but died just before it was finished.

The friendship and support of Robin Helliwell has been a constant throughout my adult life. Likewise, my sister Lucy Seal, and many other family members too numerous to list individually. In my professional life, in addition to those who gave feedback, thank you to Alan Dyke, Richard Care, and Gareth Sylvester-Bradley, all influential and supportive beyond the call of duty.

Nat’s Bit

When I told my wife, Lamaan, that I was planning to write another book, her immediate reaction was not one of horror. For that, and for her constant encouragement, I owe her many thanks.

Hat tip to my sister, Lois Pryce, and brother-in-law, Austin Vince, whose motorcycle journeys, books, and films inspired the overland travel planning application used in the worked example code.

And thanks to Oliver and Alex. Now that the book is finished, I am once again available for consultancy in music and games programming.