"Why Apache Harmony" or "How to use Java 8 on Android"

Question

Most of us have heard by now of the cool features Java 8 will bring, but Android will not support it. This is because of Google using Apache Harmony for Android. This is what is keeping us (the android app developers) from improving our code with lambdas, default implementations in interfaces, switching on a String and a lot more. Surely, we will handle for some time, but what if some libraries we use in our apps start to use Java 8 features? As far as I know, this will not work (please correct me if wrong). This creates incompatibility between Standard-Java and Android-Java. It cannot be what Google intends, or at least I can't think of a reason why a company, developing a widely adopted operating system, would wan't to permanently stay with an old Java version.

Questions:

• Why do they use Apache Harmony?
• Why can't they adopt a newer version of java?
• If they don't want Oracle's Java, why can't they use a subset of OpenJDK (licensing noob here)?
• Do you know of any plans to update the used Java version?
• Do you know of any way to use Java 8 classes on current Android systems?

Solution 1

Why do they use Apache Harmony?

Because Sun refused to provide Google with a license for Sun (now Oracle) Java under terms that were acceptable. Google and Sun negotiated, but they ended up walking away from the deal.

^{Nitpick: in fact, the Android libraries are not Apache Harmony. They started out as based on Harmony, but the two codebases have diverged. Furthermore, the Apache Harmony project was officially "retired" in November 2011.}

Why can't they adopt a newer version of java?

Firstly, Android does not run Java(tm). It runs a language that is identical to Java with a class library that is functionally equivalent to a subset of the Java class library (+ Android-specific libraries), on a virtual machine with a different instruction set.

From a technical pespective, they could ... but only if they put in a lot of work into implementing Java 7 and Java 8 language features, library features, etc, for the Android platform.

UPDATE - As of Android 19 (KitKat) and Eclipse ADT 22.6, Android does now support the Java 7 language extensions; see http://tools.android.com/recent/eclipseadt226preview

If they don't want Oracle's Java, why can't they use a subset of OpenJDK?

I don't think that switching to OpenJDK would change anything. Oracle Java and OpenJDK are 99.9% the same.

Anyway, there may be licensing and related legal issues. (And to get a feel for that, read up on the Oracle vs Google lawsuit ... that is going to appeal.)

More likely, Google doesn't see enough commercial value to counteract the (massive) effort it would take to change, and the disruption it would cause to the Android ecosystem ... which already suffers from problems with fragmentation.

Do you know of any plans to update the used Java version?

No I don't. It doesn't mean that there aren't plans, but if there are, they are not public.

Do you know of any way to use Java 8 classes on current Android systems?

You could port them. Or at least, you could try to port them. (Some Java APIs have an intimate relationship with the native code side of the JVM ... and that could make porting problematic.)

Solution 2

Do you know of any way to use Java 8 classes on current Android systems?

There are a few libraries which backport parts of Java 8 API (see the update section below for native support of these APIs in the latest Android versions):

• ThreeTenABP backport of Java 8 date and time API optimised for Android
• Stream support is a backport of the Java 8 java.util.function (functional interfaces) and java.util.stream (streams) API for users of Java 6 or 7 supplemented with selected additions from java.util.concurrent which didn't exist back in Java 6.

And you can use retrolambda (along with gradle-retrolambda plugin) to utilize lambdas in Android development.

---

UPDATE

Android Studio 3.0 started to provide built-in support for some of Java 8 language features, which are:

• Lambda expressions
• Method references
• Type Annotations (information is available at compile time, but not at runtime)
• Repeating annotations
• Default and static interface methods

Also starting from API level 24 the following Java 8 API are available:

• java.util.stream
• java.util.function
• java.lang.FunctionalInterface
• java.lang.annotation.Repeatable
• java.lang.reflect.AnnotatedElement.getAnnotationsByType(Class)
• java.lang.reflect.Method.isDefault()

API level 26 (Android O) added java.time API support.

---

UPDATE 2020/01/17

Android Studio 4.0 includes support for using a number of Java 8 language APIs, by using technique called desugaring, without requiring a minimum API level for your app:
https://developer.android.com/studio/preview/features#j8-desugar

The following set of APIs is supported in this release:

• Sequential streams (java.util.stream)
• A subset of java.time
• java.util.function
• Recent additions to java.util.{Map,Collection,Comparator}
• Optionals (java.util.Optional, java.util.OptionalInt and java.util.OptionalDouble) and some other new classes useful with the above APIs
• Some additions to java.util.concurrent.atomic (new methods on AtomicInteger, AtomicLong and AtomicReference)
• ConcurrentHashMap (with bug fixes for Android 5.0)

To support these language APIs, D8 compiles a separate library DEX file that contains an implementation of the missing APIs and includes it in your app. The desugaring process rewrites your app’s code to instead use this library at runtime.

To enable support for these language APIs, include the following in your module’s build.gradle file:

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled true
  }

  compileOptions {
    // Flag to enable support for the new language APIs
    coreLibraryDesugaringEnabled true
    // Sets Java compatibility to Java 8
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
  }
}

dependencies {
  coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:1.0.4'
}

More technical details on how desugaring is implemented, can be found in Jake Wharton's articles:

• Android's Java 8 Support
• Android's Java 9, 10, 11, and 12 Support
• D8 Library Desugaring

Solution 3

Update.

Android is planning to use the OpenJDK. Possibly because they are thinking like you and wants to use the Java 8 features. See this

Comments

[matbrgz]

Retroweaving might be an option.

[tilpner]

I don't think that changes OpenJDK anything. Oracle Java and OpenJDK are 99.9% the same.: Here it says Oracle JDK is based on the OpenJDK source code. Why would it cause problems then if they are both based on the same code (assuming the congruency is big enough)?

[Stephen C]

@StackOverflowException - You miss my point. My point is that since Oracle and OpneJDK are so close, it would make no difference to the number / kind of problems if they ported OpenJDK rather than Oracle. (And anyway, they can't port Oracle Java for copyright, etc reasons).

[Stephen C]

@StackOverflowException - As to whether they could legally port OpenJDK, you'd need to talk to the lawyers. I think they could, but it is likely to lead to another costly and time consuming lawsuit ... over something that Oracle's lawyers plausible or semi-plausible that dredge up. (You need to understand what is going on here. Oracle, Apple, Microsoft are all scared of losing market share to Google and other Android manufacturers. They are trying to use the courts to stop it / them.)

[matbrgz]

If the implementation is the same license they can port.

[Stephen C]

@ThorbjørnRavnAndersen - 1) If we are talking about Oracle and OpenJDK, the licenses are not the same. 2) There are other things to consider; e.g. patents and trademarks, and the possibility that Oracle to "try it on" with another lawsuit.

[matbrgz]

I was thinking of the Android license versus the OpenJDK license. But it is an academic exercise - to my understanding it "just" requires ensuring that the Dalvik VM supports the byte codes implementing the new things. It will be quite interesting if Google will implement those too, or stay away due to the ferocity of Oracle.

[Stephen C]

I think there's more to it than your "just". For example, 1) changes to the reflection APIs, 2) new core APIs designed to support programming with lambdas, 3) changes to debuggers, etc.

[Stephen C]

AFAIK, these options were not available when the Question was first asked and answered ...

[Admin]

"More likely, Google doesn't see enough commercial value to counteract the (massive) effort it would take to change" - just one word: Swift.

[Christopher Rucinski]

@StephenC and your point is? The answer was for future reference.

[Stephen C]

Interesting. However. Read the update at the bottom of the linked article. Also, track what appears in this file ... android.googlesource.com/platform/libcore.git/+/master/…