Are all android apps java

Jake Wharton

Android’s Java 9, 10, 11, and 12 Support

27 November 2018

Note: This post is part of a series on D8 and R8, Android’s new dexer and optimizer, respectively. For an intro to D8 read “Android’s Java 8 support”.

The first post in this series explored Android’s Java 8 support. Having support for the language features and APIs of Java 8 is table stakes at this point. We’re not quite there with the APIs yet, sadly, but D8 has us covered with the language features. There’s a future promise for the APIs which is essential for the health of the ecosystem.

A lot of the reaction to the previous post echoed that Java 8 is quite old. The rest of the Java ecosystem is starting to move to Java 11 (being the first long-term supported release after 8) after having toyed with Java 9 and 10. I was hoping for that reaction because I mostly wrote that post so that I could set up this one.

With Java releases happening more frequently, Android’s yearly release schedule and delayed uptake of newer language features and APIs feels more painful. But is it actually the case that we’re stuck with those of Java 8? Let’s take a look at the Java releases beyond 8 and see how the Android toolchain fares.

Java 9

The last release on the 2 — 3 year schedule, Java 9 contains a few new language features. None of them are major like lambdas were. Instead, this release focused on cleaning up some of the sharp edges on existing features.

Concise Try With Resources

Prior to this release the try-with-resources construct required that you define a local variable (such as try (Closeable bar = foo.bar()) ). But if you already have a Closeable , defining a new variable is redundant. As such, this release allows you to omit declaring a new variable if you already have an effectively-final reference.

This feature is implemented entirely in the Java compiler so D8 is able to dex it for Android.

Unlike the lambdas or static interface methods of Java 8 which required special desugaring, this Java 9 feature becomes available to all API levels for free.

Anonymous Diamond

Java 7 introduced the diamond operator which allowed omitting a generic type from the initializer if it could be inferred from the variable type.

This cut down on redundant declarations, but it wasn’t available for use on anonymous classes. With Java 9 that is now supported.

Once again this is entirely implemented in the Java compiler so the resulting bytecode is as if String was explicitly specified.

Because there is nothing interesting in the bytecode, D8 handles this without issue.

Yet another language feature available to all API levels for free.

Private Interface Methods

Interfaces with multiple static or default methods can often lead to duplicated code in their bodies. If these methods were part of a class and not an interface private helper functions could be extracted. Java 9 adds the ability for interfaces to contain private methods which are only accessible to its static and default methods.

This is the first language feature that requires some kind of support. Prior to this release, the private modifier was not allowed on an interface member. Since D8 is already responsible for desugaring default and static methods, private methods were straightforward to include using the same technique.

Static and default methods are supported natively in ART as of API 24. When you pass —min-api 24 for this example, the static method is not desugared. Curiously, though, the private static method is also not desugared.

We can see that the getHey() method’s access flags still contain both PRIVATE and STATIC . If you add a main method which calls hey() and push this to a device it will actually work. Despite being a feature added in Java 9, ART allows private interface members since API 24!

Those are all the language features of Java 9 and they all already work on Android. How about that.

The APIs of Java 9, though, are not yet included in the Android SDK. A new process API, var handles, a version of the Reactive Streams interfaces, and collection factories are just some of those which were added. Since libcore (which contains implementation of java.* ) and ART are developed in AOSP, we can peek and see that work is already underway towards supporting Java 9. Once included included in the SDK, some of its APIs will be candidates for desugaring to all API levels.

String Concat

The new language features and APIs of a Java release tend to be what we talk about most. But each release is also an opportunity to optimize the bytecode which is used to implement a feature. Java 9 brought an optimization to a ubiquitous language feature: string concatenation.

If we take this fairly innocuous piece of code and compile it with Java 8 the resulting bytecode will use a StringBuilder .

The bytecode contains the code we otherwise would have written if the language didn’t allow simple concatenation.

If we change the compiler to Java 9, however, the result is very different.

The entire StringBuilder usage has been replaced with a single invokedynamic bytecode! The behavior here is similar to how native lambdas work on the JVM which was discussed in the last post.

At runtime, on the JVM, the JDK class StringConcatFactory is responsible for returning a block of code which can efficiently concatenate the arguments and constants together. This allows the implementation to change over time without the code having to be recompiled. It also means that the StringBuilder can be pre-sized more accurately since the argument’s lengths can be queried.

If you want to learn more about why this change was made, Aleksey ShipilГ«v gave a great presentation on the motivations, implementation, and resulting benchmarks of the change.

Since the Android APIs don’t yet include anything from Java 9, there is no StringConcatFactory available at runtime. Thankfully, just like it did for LambdaMetafactory and lambdas, D8 is able to desugar StringConcatFactory for concatenations.

This means that all of the language features of Java 9 can be used on all API levels of Android despite changes in the bytecode that the Java compiler emits.

But Java is now on a six-month release schedule making Java 9 actually two versions old. Can we keep it going with newer versions?

Java 10

The only language feature of Java 10 was called local-variable type inference. This allows you to omit the type of local variable by replacing it with var when that type can be inferred.

This is another feature implemented entirely in the Java compiler.

No new bytecodes or runtime APIs are required for this feature to work and so it can be used for Android just fine.

Of course, like the versions of Java before it, there are new APIs in this release such as Optional.orElseThrow , List.copyOf , and Collectors.toUnmodifiableList . Once added to the Android SDK in a future API level, these APIs can be trivially desugared to run on all API levels.

Java 11

Local-variable type inference was enhanced in Java 11 to support its use on lambda variables. You don’t see types used in lambda parameters often so a lot of people don’t even know this syntax exists. This is useful when you need to provide an explicit type to help type inference or when you want to use a type-annotation on the parameter.

Just like Java 10’s local-variable type inference this feature is implemented entirely in the Java compiler allowing it to work on Android.

New APIs in Java 11 include a bunch of new helpers on String , Predicate.not , and null factories for Reader , Writer , InputSteam , and OutputStream . Nearly all of the API additions in this release could be trivially desugared once available.

A major API addition to Java 11 is the new HTTP client, java.net.http . This client was previously available experimentally in the jdk.incubator.http package since Java 9. This is a very large API surface and implementation which leverages CompletableFuture extensively. It will be interesting to see whether or not this even lands in the Android SDK let alone is available via desugaring.

Nestmates

Like Java 9 and its string concatenation bytecode optimization, Java 11 took the opportunity to fix a long-standing disparity between Java’s source code and its class files and the JVM: nested classes.

In Java 1.1, nested classes were added to the language but not the class specification or JVM. In order to work around the lack of support in class file, nesting classes in a source file instead creates sibling classes which use a naming convention to convey nesting.

Compiling this with Java 10 or earlier will produce two class files from a single source file.

As far as the JVM is concerned, these classes have no relationship except that they exist in the same package.

This illusion mostly works. Where it starts to break down is when one of the classes needs to access something that is private in the other.

When these classes are made siblings, Outer$Inner.sayHi() is unable to access Outer.name because it is private to another class.

In order to work around this problem and maintain the nesting illusion, the Java compiler adds a package-private synthetic accessor method for any member accessed across this boundary.

This is visible in the compiled class file for Outer .

Historically this has been at most a small annoyance on the JVM. For Android, though, these synthetic accessor methods contribute to the method count in our dex files, increase APK size, slow down class loading and verification, and degrade performance by turning a field lookup into a method call!

In Java 11, the class file format was updated to introduce the concept of nests to describe these nesting relationships.

The output here has been trimmed significantly, but the two class files are still produced except without an access$000 in Outer and with new NestMembers and NestHost attributes. These allow the VM to enforce a level of access control between package-private and private called nestmates. As a result, Inner can directly access Outer ’s name field.

ART does not understand the concept of nestmates so it needs to be desugared back into synthetic accessor methods.

Unfortunately, at the time of writing, this does not work. The version of ASM, the library used to read Java class files, predates the final implementation of nestmates. Beyond that, though, D8 does not support desugaring of nest mates. You can star the D8 feature request on the Android issue tracker to convey your support for this feature.

Without support for desugaring nestmates it is currently impossible to use Java 11 for Android. Even if you avoid accessing things across the nested boundary, the mere presence of nesting will fail to compile.

Without the APIs from Java 11 in the Android SDK, its single language feature of lambda parameter type inference isn’t compelling. For now, Android developers are not missing anything by being stuck on Java 10. That is, until we start looking forward…

Java 12

With a release date of March 2019, Java 12 is quickly approaching. The language features and APIs of this release have been in development for a few months already. Through early-access builds, we can download and experiment with these today.

In the current EA build, number 20, there are two new language features available: expression switch and string literals.

Once again, both of these features are implemented entirely as part of the Java compiler without any new bytecodes or APIs.

We can push this to a device to ensure that it actually works at runtime.

This works because the bytecode for expression switch is the same as the “regular” switch we would otherwise write with an uninitialized local, case blocks with break , and a separate return statement. And a multi-line string literal is just a string with newlines in it, something we’ve been able to do with escape characters forever.

As with all the other releases covered, there will be new APIs in Java 12 and it’s the same story as before. They’ll need added to the Android SDK and evaluated for desugaring capability.

Hopefully by the time Java 12 is actually released D8 will have implemented desugaring for Java 11’s nestmates. Otherwise the pain of being stuck on Java 10 will go up quite a bit!

Java 8 language features are here and desugaring of its APIs are coming (star the issue!). As the larger Java ecosystem moves forward to newer versions, it’s reassuring that every language feature between 8 and 12 is already available on Android.

With Java 9 work seemingly happening in AOSP (cross your fingers for Android P+1), hopefully we’ll have a new batch of APIs in the summer as candidates for desugaring. Once that lands, the smaller releases of Java will hopefully yield faster integration into the Android SDK.

Despite this, the end advice remains the same as in the last post. It’s vitally important to maintain pressure on Android for supporting the new APIs and VM features from newer versions of Java. Without APIs being integrated into the SDK they can’t (easily) be made available for use via desugaring. Without VM features being integrated into ART D8 bears a desugaring burden for all API levels instead of only to provide backwards compatibility.

Before these posts move on to talk about R8, the optimizing version of D8, the next one will cover how D8 works around version-specific and vendor-specific bugs in the VM.

(This post was adapted from a part of my Digging into D8 and R8 talk that was never presented. Watch the video and look out for future blog posts for more content like this.)

Источник

Learn Java for Android Development: Introduction to Java

In this tutorial series, you’ll become familiar with Java, the programming language used to develop Android applications. Our goal is to prepare those already familiar with one programming language, such as PHP or Objective-C, to become comfortable working with the Java programming language and dive into Android app development. In this tutorial, you’ll get a brief introduction to Java fundamentals, including object oriented programming, inheritance and more. If you’re new to Java, or just looking to brush up on the details, then this is the tutorial series for you!

Getting Started

As far as prerequisites go, we’re going to assume you understand how to program (perhaps in PHP, or Visual Basic or C++), but that you are unfamiliar with the specifics of programming in the Java language. We aren’t going to teach you to program; we’re going to provide you with clear examples of commonly used Java language constructs and principles, while pointing out some Android-specific tips and tricks.

What You’ll Need

Technically, you don’t need any tools to complete this tutorial but you will certainly need them to develop Android applications.

To develop Android applications (or any Java applications, for that matter), you need a development environment to write and build applications. Eclipse is a very popular development environment (IDE) for Java and the preferred IDE for Android development. It’s freely available for Windows, Mac, and Linux operating systems.

For complete instructions on how to install Eclipse (including which versions are supported) and the Android SDK, see the Android developer website.

What is Java?

Android applications are developed using the Java language. As of now, that’s really your only option for native applications. Java is a very popular programming language developed by Sun Microsystems (now owned by Oracle). Developed long after C and C++, Java incorporates many of the powerful features of those powerful languages while addressing some of their drawbacks. Still, programming languages are only as powerful as their libraries. These libraries exist to help developers build applications.

Some of the Java’s important core features are:

• It’s easy to learn and understand
• It’s designed to be platform-independent and secure, using
  virtual machines
• It’s object-oriented

Android relies heavily on these Java fundamentals. The Android SDK includes many standard Java libraries (data structure libraries, math libraries, graphics libraries, networking libraries and everything else you could want) as well as special Android libraries that will help you develop awesome Android applications.

Why is Java Easy to Learn?

Java is easy to learn for a variety of reasons. There’s certainly no shortage of Java resources out there to help you learn the language, including websites, tutorials, books, and classes. Java is one of the most widely discussed, taught, and used programming languages on the planet. It’s used for many different types of programming projects, no matter their scale, from web applications to desktop applications to mobile applications.

If you’re coming from a traditional programming background like C or C++, you’ll find Java syntax quite similar. If you’re not, then take comfort in knowing that you’ve chosen one of the easiest languages to learn. You’ll be up and running in no time at all.

Finally, Java is one of the most human-readable languages out there, by which we mean that a person who knows nothing about programming can often look at some Java code and have at least an inkling what it’s doing. Consider the following example:

If you simply read the code aloud, you can pretty much tell that this snippet of code is doing. There’s a single letter variable called character. If the character variable equals the letter a, then we do something (call the doSomething() method), otherwise we do something else (by calling the doSomethingElse() method).

Why is Platform Independence Important?

With many programming languages, you need to use a compiler to reduce your code down into machine language that the device can understand. While this is well and good, different devices use different machine languages. This means that you might need to compile your applications for each different device or machine language—in other words, your code isn’t very portable. This is not the case with Java. The Java compilers convert your code from human readable Java source files to something called “bytecode” in the Java world. These are interpreted by a Java Virtual Machine, which operates much like a physical CPU might operate on machine code, to actually execute the compiled code. Although it might seem like this is inefficient, much effort has been put into making this process very fast and efficient. These efforts have paid off in that Java performance in generally second only to C/C++ in common language performance comparisons.

Android applications run in a special virtual machine called the Dalvik VM. While the details of this VM are unimportant to the average developer, it can be helpful to think of the Dalvik VM as a bubble in which your Android application runs, allowing you to not have to worry about whether the device is a Motorola Droid, an HTC Evo, or the latest toaster running Android. You don’t care so long as the device is Dalvik VM friendly—and that’s the device manufacturer’s job to implement, not yours.

Why is Java Secure?

Let’s take this bubble idea a bit further. Because Java applications run within the bubble that is a virtual machine, they are isolated from the underlying device hardware. Therefore, a virtual machine can encapsulate, contain, and manage code execution in a safe manner compared to languages that operate in machine code directly. The Android platform takes things a step further. Each Android application runs on the (Linux-based) operating system using a different user account and in its own instance of the Dalvik VM. Android applications are closely monitored by the operating system and shut down if they don’t play nice (e.g. use too much processing power, become unresponsive, waste resources, etc.). Therefore, it’s important to develop applications that are stable and responsive. Applications can communicate with one another using well-defined protocols.

Compiling Your Code

Like many languages, Java is still a compiled language even though it doesn’t compile all the way down to machine code. This means you, the developer, need to compile your Android projects and package them up to deploy onto devices. The Eclipse development environment (used with the Android Development plug-in) makes this pretty painless. In Eclipse, automatic compilation is often turned on by default. This means that every time you save a project file, Eclipse recompiles the changes for your application package. You immediately see compile errors. Eclipse also interprets Java as you type, providing handy code coloring and formatting as well as showing many types of errors as you go. Often, you can click on the error and have Eclipse automatically fix a typo, or add an import statement, or provide a method stub for you, saving lots of typing.

You can still manually compile your code if you so desire. Within Eclipse, you’ll find the Build settings under the project menu. If you have “Build Automatically” turned on, you can still choose the “Clean…” option that will allow you to do full rebuild of all files. If “Build Automatically” is turned off, “Build All” and “Build Project” menu options are enabled. «Build All» means to build all of the projects in the workspace. You can have many projects in an Eclipse workspace.

The build process, for regular Java projects, results in a file with the extension of JAR – Java ARchive. Android applications take JAR files and package them for deployment on devices as Android PacKage files with an extension .apk. These formats not only include your compiled Java code, but also any other resources, such as strings, images, or sound files, that your application requires to run as well as the Application Manifest file, AndroidManifest.xml. The Android Manifest file is a file required by all Android applications, which you use to define configuration details about your app.

What is an Object Oriented Programming Language?

Okay. Time for a very brief and 20,000 foot view of object oriented programming (OOP). OOP is a programming style or technique that relies upon the definition of data structures called objects. For those new to OOP, an object can be thought of much like a custom data type. For example, you might have a Dog object, which represents the blueprint for a generic dog, with a name, breed, and gender. You could then create different instances of the Dog object to represent specific dogs. Each Dog object must be created by calling its constructor (a method that has the same name as the object itself, and may or may not have parameters for setting initial values). For example, the following Dog objects use a constructor with three parameters (name, breed, gender):

So where is this Dog object defined? Well, here we need to begin defining some of the fundamental building blocks of the Java programming language. A class provides a definition for an object. Therefore, there is a Dog class somewhere—either defined by you or in some library somewhere. Generally speaking, a class will be defined in its own file, with the filename matching the class name (e.g. Dog.java). There are exceptions to this rule, such as classes defined within other classes (when a class is declared within a class, it is generally defined for use within the parent class only as a helper class, and referred to as an inner class).

When you want to reference an object from within another class, you need to include an import statement in the top of your class file, much like you would use a #include statement in a compiled language like C.

A class typically describes the data and behavior of an object. The behavior is defined using class methods. Method is the common term for a subroutine in an OOP language. Many common object classes are defined in shared class libraries like software development kits (SDKs), whereas others are defined by you, the developer, for your own purposes. Software is then built up by using and manipulating object instances in different ways.

Please realize this is a very generalized definition of OOP. There are entire books written on this subject. If you’d like to know more about OOP, here are a few resources you might want to check out:

Note: We use a lot of different terminology in this tutorial. There are multiple ways to refer to a given concept (e.g. superclass vs. parent class), which is confusing to those new to object oriented programming. Different developers use different terms, and so we have tried to mention synonyms where appropriate. Deciding which terms you will use is a personal choice.

Understanding Inheritance

Here is another important Java concept you’ll run into a lot: inheritance. Simply put, inheritance means that Java classes (and therefore objects) can be organized into hierarchies with lower, more specific, classes in the hierarchy inheriting behavior and traits from higher, more generic, classes.

This concept is best illustrated by example. Let’s pretend we are developing a Java application to simulate an aquarium. This aquarium has some fish in it. Therefore, we might define a class to represent a fish. This class, called Fish, could include some data fields (also called attributes, or class member variables) to describe a fish object: species, color and size; as well as some of its behavior in the form of methods (also called subroutines, or functions in procedural languages), like eat(), sleep(), and makeBabyFish().

A special type of method, called a constructor, is used to create and initialize an object; constructors are named the same as their class and may include parameters. The following Fish class has two constructors: one for creating a generic Fish object and another for constructing a specific Fish object with some initial data. You’ll also see that the Fish class has two eat() methods: one for eating something random, and another for eating another fish, which would be represented by another instance of the Fish class:

Classes can be organized into hierarchies, where a derived class (or subclass) includes all the features of its parent class (or superclass), but refines and adds to them to define a more specific object using the extends keyword. This is called inheritance.

For example, the Fish class might have two subclasses: FreshwaterFish and SaltwaterFish. These subclasses would have all the features of the Fish class, but could further customize the objects through new attributes and behaviors or modified behaviors from the parent class Fish. For example, the FreshwaterFish class might include information about the type of freshwater environment lived in (e.g. river, lake, pond, or puddle). Similarly, the SaltwaterFish class might customize the makeBabyFish() method such that the fish eats its mate after breeding (as defined in the super class) by using the override mechanism, like this:

Organizing Object Behavior with Interfaces

In Java, you can organize object behaviors in what are called interfaces. While a class defines an object, an interface defines some behavior that can be applied to an object. For example, we could define a Swimmer interface that provides a set of methods that are common across all objects that can swim, whether they are fish, otters, or submergible androids. The Swimmer interface might specify four methods: startSwimming(), stopSwimming(), dive(), and surface().

A class like Fish could then implement the Swimmer interface (using the implements keyword) and provide implementations of the swimming behavior:

Organizing Classes and Interfaces with Packages

Class hierarchies, such as our fish classes, can then be organized into packages. A package is simply a set of classes and interfaces, bundled together. Developers use namespaces to uniquely name packages. For example, we could use com.mamlambo.aquarium or com.ourclient.project.subproject as our package name to keep track of our fish-related classes.

Wrapping Up

Wow! You’ve just embarked on a crash-course in Java for Android development. We’ve covered a pretty intense amount of material here, so let things settle for a bit before moving on to the next lesson of this tutorial series. In Lesson 2, we switch our focus to the nitty-gritty details of Java syntax.

You’ve only scratched the surface of Java development for Android development. Check out all the other great tutorials on Mobiletuts+ to dive deeper into Java and Android development. Good luck!

About the Authors

Mobile developers Lauren Darcey and Shane Conder have coauthored several books on Android development: an in-depth programming book entitled Android Wireless Application Development and Sams TeachYourself Android Application Development in 24 Hours. When not writing, they spend their time developing mobile software at their company and providing consulting services. They can be reached at via email to androidwirelessdev+mt@gmail.com, via their blog at androidbook.blogspot.com, and on Twitter @androidwireless.

Need More Help Writing Android Apps? Check out our Latest Books and Resources!

Related Tutorials:

Useful Resources:

If you want to get started with Android development, an Android app template is a great place to start. Check out the selection on Envato Market—or you could look more specifically for Java items.

Android app templates on Envato Market

You can also find Android developers on Envato Studio to help you with everything from UI design to creating a native Android app.

Android developers on Envato Studio

Источник