Why starting a new Android project with Java is a bad idea
I’m a programming language sceptic. i.e. I don’t jump on every new language and try to learn five new ones every year. When I find a good one I’ll stick with it. I used Java exclusively as my programming language for 20 year. I did not jump on Kotlin when the cool people did before last year. I explain my reasoning of resisting in this earlier post.
In Snapp Mobile, we’ve now switched to Kotlin in all of our new project and we’re not looking back. I think we have done the right decision. Kotlin on Android is the future while Java is the past. Let me explain why.
Android developer mindshare is going to Kotlin
If you follow the Android developer community in any way you can feel the excitement of the new language. It’s not just nerds wanting something new. No. It’s hundreds of people talking, writing and commenting about possibilities and ways to improve the way we work every day.
The percentage of Android developers working in Java is dropping rapidly. A project started today will live on at least couple of years but probably beyond that. I predict that in a year or two it is going to be nearly impossible to find developers willing to work in Java or at least being motivated to do so. Going with Java is going to create a legacy system from the day one. Maintaining and improving the codebase will become more and more difficult when time passes. Sooner or later you would be converting the codebase to Kotlin so why not just start with Kotlin from the get-go.
We saw this very same process happening on iOS just few years ago. Now that Swift is commonplace it’s nearly impossible to find anyone willing to maintain ObjC codebase. Projects have to be migrated and that can be costly.
Take a look what GDEs (Google Developer Experts) think about Kotlin on Android. TL;DR: majority of GDEs have already completely shifted to Kotlin in their daily work. Most of them think Kotlin is production ready. Concerns like Mark Allison’s ones are getting resolved very rapidly.
Kotlin is not a FAD
Google is not shy to introduce something just to let it die later. Kotlin on Android is not one of these projects. There’s heavy weight behind Kotlin from Google. Google was very visible in the first-ever KotlinConf so much so that most of the questions in the open FAQ session were about Kotlin’s future on Android. We also saw the Google Android tools team present in the event.
We’re seeing a shift in Google’s hiring policies. Many new Googlers are heavy Kotlin users and advocates.
Another good example of Google’s dedication is the recently released KTX for Android. KTX for Android is a set of Kotlin extensions specifically for Android devs making our life easier.
Code quality improves
While we’re still establishing best practices and patterns on some parts of Kotlin development the language is forcing some very good habits on developers. Null-safety alone improves stability of your projects in most cases.
Also, less code, less bugs:
Less code
Less code is never a redeeming feature of a language alone. Readability is always more important than length, or lack thereof, of the code. Always! However, with Kotlin you get both. The language developers keep referring to Kotlin as a concise language. They’re not wrong.
Of course, it is possible to write bad code in every language. It will take time for all the best practices to evolve in Android Kotlin circles but they will. We already Kotlin Android Style Guide published by Google which is a great starting point.
Less code, when done right, leads into less bugs. When you let framework take care of certain mundane aspects of coding like boilerplate you can concentrate on building what matters. Less code also makes reading code faster. It is much easier to see where behaviour of a Kotlin data class differs from default than Java Bean class with all of its accessor methods.
Risk is minimal, Java interop
Kotlin does not lock a project to Kotlin permanently. It is possible to integrate new features built in Java to your codebase in later stages due to the complete Java interop of Kotlin programming language.
Kotlin isn’t a new thing, it’s ready
When Swift was first introduced by Apple it took some time for developers to jump on it. Getting on a completely new programming language is risky. APIs change, tools lack features etc. However, today, no new iOS project will be started with ObjC.
Kotlin is not a new language. In fact, Kotlin was introduced before Swift announced by Apple. It is more mature, tested and stable than Swift at this point. It has been possible to build Kotlin apps on Android for years before the official support was introduced last year.
Kotlin and Swift have a lot in common
Good ideas tend to be repeated, copied and imitated. It’s not surprising that the designers of Kotlin and Swift ended up with similar solutions to similar issues.
The benefit of Swift and Kotlin being so similar is that it’s now easy for the iOS team to read Android code and the other way around. Sending over program logic is trivial. You can exchange code between the teams without having to explain details every time.
Tool support is already there
JetBrains have been building Kotlin tools for years. Google’s Android Studio is based on the JetBrain’s IntelliJ Idea. After the IO announcement Google and JetBrains are now working together with Android Studio Kotlin tooling. This tooling is based on the long running work JetBrains have been doing in the past years. Unlike when Swift was first introduced on iOS, with Kotlin we’re hitting the ground running. We already have sophisticated refactoring tools, static analysis tools, formatting etc. We can even copy-paste a piece of Java code from Stackoverflow to our project and Android Studio will automagically translate it into Kotlin.. with very high success rate, I may add.
Kotlin is evolving rapidly
JetBrains is very active on pushing new features to the already comprehensive language. New features like Coroutines are enabling new ways to improve your codebase very constantly.
“But I / our developers don’t know Kotlin”
I think this is the argument that deserves the most attention in the decision process as an argument for going with Java. There’s no contest between the amount of experienced Java developers vs. experienced Kotlin developers. Java is, after all, the most popular programming language on the planet.
However. For a Java developer Kotlin is extremely easy to learn. Any Android developer can pickup the language in two weeks and be ready for productive project work. You will only need one experienced Kotlin developer in your team and the rest will fall in place easily. Use your more experienced developer to review all pull requests in the early stage. There’s no better way to learn than having someone looking at your code and proposing improvements!
Learning new comes naturally to mobile developers. We live in a constantly changing environment all the time anyways. Investing your own time to learn Kotlin is an investment to the future. And there’s plenty of good material out there!
But don’t take only my word on it!
I’m not the only one writing about this.
TL;DR
Starting a new Android project today in Java would be a mistake.
