Java For Android

While a number of languages can be used to build Android apps, Java is the language Google encourages developers to use. However, it’s not precisely the same as the Java you may have encountered on other platforms. There are some subtle differences and peculiarities and it’s important for you as an Android developer to get your head around them.

In this tutorial, you’ll take a quick tour of Java in the Android world and find out more about the features it offers. Along the way you’ll also learn:

• How an app on Android differs from a Java program on a PC
• How to make use of Object Oriented Programming for Android
• What a Java Interface is and how you might use it to communicate with other parts of your app
• What Java Annotations are and how they provide extra information about parts of your app

This tutorial assumes you are familiar with at least one Object Oriented Programming language. It isn’t absolutely essential if you’re not, but the concepts discussed in this article will make more sense if you do.

Note: This article is somewhat different to a standard raywenderlich.com tutorial, in that it describes lots of high-level topics rather than having a follow-along sample app. You’re encouraged to give this a read before embarking on building Android apps as it gives you a great grounding in the quirks of Java for Android.

Grab a cup of your favourite “Java” and strap yourself in for a magical tour of the language — Android style!

Java and Android

Fun fact: Android doesn’t use “pure” Java! This may sound strange, because when you compare code from a traditional Java program to similar code from an Android app, you’d struggle to see the difference.

Although writing and developing an Android app will feel somewhat familiar to experienced Java developers, the familiarity ends abruptly when you compile and run. The reason you’ll find yourself in uncharted territory is the way Android handles its apps during the compilation process.

Java’s major appeal is its ability to “Write once, run everywhere”. This language is sold as the silver bullet to the expensive process of porting software from one platform to another.

This veritable marvel of software engineering is made possible thanks to what happens when a Java program compiles.

During the compilation process for most other languages, the compiler links and optimizes the program, and then it translates it into Machine Code, which is a set of instructions a computer can understand and execute when you run the program.

Although execution of machine code is fast, it’s limited because it targets the platform on which it runs. If you ever wondered why a program written for iOS platform doesn’t just work on Windows, this is one of the reasons.

Java, in contrast, does something different; instead of translating a program into machine code, the Java compiler translates it an intermediate form called Bytecode. It creates a set of instructions that are similar to machine code, but are targeted to run on a Virtual Machine (VM) instead of some specified architecture.

Using a VM means that as long as it can read and interpret the Bytecode’s instructions, the program will happily run on its host platform, ensuring cross-platform compatibility.

And now you can see why most Java programs prompt you to download the Java Runtime Environment (JRE) when you don’t have it – it’s the default VM for the majority of platforms.

Java for Android is…Different

Compiling an app for Android follows the same path as converting Java files into Bytecode. Except that it doesn’t. When the app (composed of Bytecode) installs on a device, a second step occurs during installation. The app’s Bytecode is converted into machine code that’s optimized for that Android device, improving the app’s runtime performance. This process is known as Ahead of Time compilation (AoT) and is made possible by the Android Runtime (ART) virtual machine.

Note: Ahead of Time Compilation (AoT) is a concept used across many programming languages. You can read more about it on Wikipedia.

AoT compilation only occurs in Android KitKat (4.4) and above, but it also provides backwards compatibility. Prior versions of Android relied on another virtual machine known as Dalvik. Like ART, Dalvik made changes to the Java Bytecode, converting it into a specific form that made various efficiency changes to optimize the app for the kinds of low-powered devices Android was originally designed for.

However, unlike ART, Dalvik didn’t compile the Bytecode into machine code until runtime — using an approach known as Just in Time compilation (JIT). This process is much closer to that used in Java Virtual Environments on a PC.

Android Froyo (2.2) saw an improvement when Dalvik gained the ability to profile the app during runtime for commonly used portions of Dalvik Bytecode. These instructions were then permanently translated into machine code by Dalvik to boost the app’s speed.

Note: Trace Based Just in Time Compilation (JIT) is not unique to Java, and once again, Wikipedia does a nice job of explaining it.

In either case of Android app compilation, it’s the conversion of Bytecode that makes the Java written for Android less “pure”.

The changes to the Bytecode constrain the app’s portability, thereby negating one of the promises of Java language: “Write once, run everywhere”.

Another way Android diverges from Java is with the availability of standard libraries. Java is so portable is because it relies on a standardized collection of libraries it can use across various platforms, such as networking and UI libraries.

Android offers a subset of what Java provides, and what it does provide is only for Android.