Why I Won’t Be Using Java for My Next Android Project

     Ever since its inception in 1996, Java has been no stranger to criticism. Nevertheless, it’s popularity has only continued to grow in recent years. A lot of this recent growth is due to the widespread usage of the Android platform. Before Android, Java’s verbosity was a favorite among project managers because it made it look like people were getting a lot of work done. In its early days, Java even had a purpose, to provide somewhat-secure, cross-platform web apps. But is the Sun (pun intended) about to set on the Java empire? Recent trends show that more programmers are turning away from this twenty-year-old behemoth named after a coffee bean.

     In 2016 alone, we’ve seen fewer web apps using Java, JetBrains releasing the Kotlin language for JVM, and there are even rumors of Swift for Android. We don’t have any word from the project managers yet but we can reasonably expect them to migrate from Java by the time the aliens return.

     While we wait for that day to come, we as developers can take a stand. While I’ll likely be using Java for the remainder of my Udacity projects, personal projects are a different story. But why exactly is choosing a Java alternative so appealing when building an Android app? Here are my main reasons.

Verbosity:

     Project managers aside, no one needs verbose code. Unfortunately, Java has a lot of these problems. We need to reference a class name at least twice in order to initialize it. This is even worse than it sounds, given that Java class names are notoriously long. Many modern languages are still statically typed, but have proper type inference, which fixes this problem. What about parentheses after conditional and loop conditions? Most modern languages don’t need those either. Add in other features like the “new” keyword and a semicolon after every line, and you’re sure to have a mess of code.

Closures:

     When first learning Groovy to write Gradle scripts, I couldn’t help but applaud the use of closures. This excellent feature from Swift has already taken the iOS community by storm, and Groovy closures should really be doing the same for Android. Ever used AsyncTask or Runnable? You may have noticed that only static properties (from the class calling it) can be used in their methods. Closures, on the other hand, are methods that don’t need to belong to a class. You can use any variable from the class that’s using it. We could finally see a proper completion handler pattern for Android, which would make networking code and long running tasks much more readable.

Protocols:

     While Swift for Android is still a long wait away, Swift-like features such as protocol oriented programming could be very handy in Android apps. Protocols are much more flexible than java interfaces, with features such as optional methods. The ability to use protocols would allow for much cleaner MVC design.

Typing Time:

     This goes without saying, having previously mentioned Java’s verbosity. All this unneeded syntax wastes a lot of typing time. In an age where compiled languages that read like scripting languages are common, it’s hard to make an argument in favor of the old conventions. Building software is supposed to be about productivity. Unless you’re in a workplace that measures lines of code, using a Java replacement is something to consider.

NullPointerException:

     Even the experienced programmer encounters some of these. While no magical new programming language can eliminate null pointers, there are many better ways of handling these cases. In java, before using a class that may be equal to null, you need to check if it’s “!= null” or use “instanceof”. In many cases, this is necessary simply to call a single method. Instead, if you use Kotlin or Groovy, there are special operators that can handle null pointer exceptions for you, without needing to add an extra level of indenting.

The Future:

     It took Apple 30 years to finally do something about Objective-C, so Java still has a good 10 years to live. But if you have the choice, the advantages of using an alternative are clear. From saving time to advanced features, Java replacements can greatly improve your Android development productivity. For me personally, I’ll soon be porting an iOS app I wrote over to Android. I don’t intend to use a single line of Java. The only question is: who’s it gonna be?

Kotlin, Groovy, or something else? Let me know in the comments and I'll keep you posted when I start porting the app.