Kenneth A. Kousen

Hi Jude,

In terms of testing, I have several recipes that show how to write JUnit tests with Kotlin, which can test code written in either Kotlin or Java.  (You can find an annotated listing of all the recipes here).

Mixing Java and Kotlin in the same project is easy. In fact, every Android project already does that, because the Android SDK itself is still written in Java, which shows Kotlin classes can extend Java classes, or implement Java interfaces, and so on.

So adding Kotlin to an existing Java project is certainly doable. Add the appropriate Kotlin dependencies to your build tool and go from there. The GitHub repository for the book is a mixed Java/Kotlin project. I was planning to add a handful of recipes specifically on integration, but (1) I ran out of time and (2) it's actually easy enough that it hardly required recipes for it. Just instantiate the classes from the other language and invoke their methods as usual.

Spring has great support for Kotlin. You can use Kotlin classes as Spring beans, and Spring defined a series of extension methods that make the coding simpler. It even defined a DSL for bean configuration and a DSL for defining routing functions for reactive services.

There's an interesting design consideration involved, however. In Kotlin, all classes are final (i.e., can't be extended) by default, and Spring does a lot of its job through the Proxy design pattern. That means, for example, that if you annotate a Spring service with @Transactional, Spring needs to extend the class, so each method call can be intercepted and wrapped in a transaction.

In order to make that work with Kotlin, the Spring team defined an "all-open" plugin which opens Spring-managed beans for extension. From a user point of view, it's easy. You just add the plugin and code as usual. But the fact they had to do it makes me question whether "static binding by default" (making the classes final) was a good idea in the first place.

So Spring definitely likes working with Kotlin, but will they favor it in the future? I doubt that. Spring also has excellent support for Groovy, but even though that's also a language offered in the Spring Initializr (like Kotlin), it certainly hasn't replaced Java as the primary language for Spring apps.

I have some of this documented in my book, if you're interested, but just look at the web pages for Kotlin and Spring and you'll see these issues discussed in some detail. That's also a good example of how to sell Kotlin to Java developers, because the Spring people are doing that in their Kotlin API.

The so-called "multi-platform" part of Kotlin allows you to use the same code in many different types of systems. The page here has the basic information.

Wow. It turns out the Kotlin home page https://kotlinlang.org updated *today*, so everything looks different. I don't see the same info about available systems that was there yesterday, so I guess I'll have to look around for it. But the sample GitHub repo here contains everything from iOS Swift to Cocoa to WebAssembly to Python and more. Looks promising.

I should admit, though, that almost everything I've done with Kotlin has been on the JVM. I know the multi-platform approach has a lot of advocates, though.

At first glance it looks like your lmbd function returns Unit (i.e., nothing). If you want it to return a value, you need to add :Int to the signature and add a "return" statement inside the function.

Let me say first that if I have a working application, I usually leave it alone. That said, if I wanted to port it to another language, I would start by making sure I had a good set of test cases, and if you're trying to learn Kotlin, you can write your tests (including JUnit tests) in Kotlin.

Again, the biggest advantage of Kotlin over Java is its null safety. In addition, it has excellent concurrency support in the form of coroutines. Other advantages provided by the language are modern support for sequences, builders, extension methods, and more. In fact, frameworks like Spring use Kotlin to create DSLs to configure beans or applications, leading to simpler code that's still type safe.

Anything you can do in Java, though, you can do in Kotlin, so there is no reason you could not port over your app. As I say, though, if your app already works, I'd probably live with it.

The biggest reason devs move to Kotlin is for the null safety. The language eliminates nearly all null pointer exceptions, because nullability is enforced at the compiler level. It's also a modern language, with many functional features. The other major feature that appeals to developers is the coroutines support, which makes it easier to write concurrent code.

Anything you can do in Java, you can do in Kotlin. The "killer app" these days, however, is Android. Google has declared that all new Android libraries there will be "Kotlin first".

The Spring framework support is also excellent, and they've added a few Domain Specific Languages (DSLs) in Kotlin to simplify development there.

That's what Kotlin multi-platform support is all about. The current status and some basic information can be found here

As the page says, the multi-platform capabilities include support for "JVM, Android, JavaScript, iOS, Linux, Windows, Mac and even embedded systems like STM32".

Hopefully that's what you're looking for.

The good news is that while there are a lot of constructs, there are only a handful of use cases that come up over and over again. So working with `launch` and `async` and `coroutineScope`, etc, becomes manageable. Doesn't mean you don't have to be careful, as you said, but at least you're not always starting from scratch.

Good luck with the multi-platform approach. There are some notable successes, so there are decent examples to base your work on. I just don't feel confident enough in my understanding of the other platforms yet to spend time understanding the details.

Whether Google favors Kotlin over Java because of its series of lawsuits with Oracle is always a matter of some debate. That probably contributed, but I don't think that's the only or even the biggest reason. The developer community was already in the process of adopting Kotlin for Android development, mostly because:

* Null-safety is a highly valued feature of the language
* Kotlin has inline functions, which keeps the total function count down (a significant issue in larger Android apps)
* Kotlin does some optimizing on size and space
* Kotlin is produced by JetBrains, which is the same company behind both IntelliJ IDEA and Android Studio, so the IDE integration is very good.

When Google announced back in 2017 that they were going to support Kotlin for Android apps, some people felt they were just acknowledging a move in the developer community that was already underway. Still, they did jump on it, and now everything is "Kotlin First" at Google when creating a new library.

Threading wasn't a major part of Kotlin at the beginning, but the development of coroutines and structured concurrency have made it easier to write Android apps that move off and back onto the UI thread as needed. I agree that I don't think performance is related as much to the language as to the platform itself, so the move to Kotlin doesn't really change performance all that much. That said, it's easier to get the threading right with Kotlin, which is a minimum requirement.

"In depth" is a strong word. The challenge with coroutines is that there are a lot of moving parts, so I tried to break them down into what they do and where to use them. I look at builders and dispatchers, and then how to use them.

Here are the individual recipes:

Coroutines and Structured Concurrency
* 13.1 Choosing Coroutine Builders
* 13.2 Replacing async/await with withContext
* 13.3 Working with Dispatchers
* 13.4 Running Coroutines on a Java Thread Pool
* 13.5 Cancelling Coroutines
* 13.6 Debugging Coroutines

This is part of an annotated table of contents I added to my blog in my blog.

For the record, Groovy 3 released RC 2 (the last release candidate) about a week ago. Follow the @ApacheGroovy twitter feed to see when the full version is released. There's an InfoQ article out now about the new features, which you can find here.

Hi Mike (from Connecticut in the US),

The Android world is in a bit of flux right now. Originally apps were written in Java, with Activities, Fragments, and so on instantiated and configured directly. Now the preferred language is Kotlin, and a lot of people are moving to more of a component model. The so-called "jetpack" components are used for navigation, mapping to databases, and more.

I love the Head First Android Development book as a learning tool for Android, but unfortunately it is still in Java. The concepts are great, though. There is also a "Big Nerd Ranch Guide to Android", and the latest edition uses Kotlin. My book is more general than just Android, but has some Android examples in it.

Regarding functional programming, the book you linked to has a newer edition, called Modern Java in Action, but the streams, lambdas, and method references work the same way. I illustrated the similar concepts in Kotlin. For example, Kotlin collections have functions like map and filter, and Kotlin sequences are essentially Java streams. Concepts like "higher order functions" are just library calls that take lambdas as arguments, and aren't much different from their counterparts in Java (like forEach taking a Consumer).

In other words, I think you'd find my book straightforward. If not, feel free to ask questions here, or contact me directly.

Thanks for the kind words about Modern Java Recipes. The Kotlin Cookbook takes the same philosophy, in that it's a series of short descriptions about solving specific problems. I mostly collected the ideas from either what I was learning at the time or questions being asked in the public Slack channel.

The difference between the cookbook approach and a regular book is that in the cookbook I don't assume you are learning the language step by step. I use whatever the language provides, practically from the first chapter. That means it probably shouldn't be your only Kotlin book, but it's a nice supplement to standard expositions like Kotlin in Action (which is still a great book, even if it's a little dated now).

People like Brian Goetz (super architect at Oracle) claim that eventually Java fibers will put coroutines out of business, but we'll see. I think it's going to be a long time before they appear in the language in a usable form.

The biggest issue I have with Kotlin coroutines is that people talk about them like they're simple. It's true that the resulting code is way simpler than using callbacks, but I like to say "just because coroutines make it easy to write concurrent code, doesn't mean coding concurrency is easy".

The "structured" concurrency Kotlin employs by using things like coroutineScope is really helpful, but no matter how you deal with it, there are a lot of moving parts to understand. That said, the more I get used to them the more I like them. I suspect they will be mostly hard for library developers, but that clients will have a much easier time.

In Android, one of the dominant libraries for accessing restful web services is called RetroFit (built on top of OkHttp). Both have recently been revised to support coroutines, and they're great.

So my only real reservation about them is complexity. The learning curve (at least for me) was not a small one. It took me a long time to write that chapter in the book. Hopefully I did a decent job of it. Also see Venkat Subramaniam's book Programming Kotlin for some good examples and explanations of them.

OOP and FP are used together in both Java and Kotlin. You use classes and interfaces for your design (like Activity or Intent or ViewModel) and functional coding like map and filter operations when working with collections or sequences. So it's really a combination. There are many good examples of Android apps already written in Kotlin (many provided directly by Google) that illustrate the preferred practices.

Good luck