I want to migrate my Maven project to JDK 11. But I want to keep support for JDK 8.
Problems so far are:
<maven.compiler.release> is supported since Java 9. How to use it in JDK 11 but ignore it in JDK 8?
I'm using Apache HttpClient in Java 8. Java 11 has a new built in HTTP client and Apache HttpClient 4.x has some issues on Java 11. Is there a way to use JDK's HttpClient in Java 11 and Apache's in Java 8?
How to deal with those problems? Is it possible to make a project work in different JDKs like this? Or is the only way to keep the smallest commonality for everything?
If you still have to support Java 8, stay on Java 8. Chances are that you will find more problems when trying to achieve this and it might cost you a lot of time.
When you can get rid of Java 8 support, migrate the whole application once to Java 11 and save your time right now.
I've just tried to run my app compiled using Java 8 on an Android 4.0 device. While I'm used to taking great care to look at the Android API levels in the Android documentation to make sure I'm only using APIs that are available on Android 4.0, I'm not so used to making sure I'm not using any features in Java itself that aren't available on Android 4.0.
Consider the following code, it tries to import the initializeScrollbars() API from View class because, for whatever reason, it has been removed from the official SDK:
try {
final Method initializeScrollbars = android.view.View.class.getDeclaredMethod("initializeScrollbars", TypedArray.class);
initializeScrollbars.invoke(this, a);
} catch (NoSuchMethodException | InvocationTargetException | IllegalAccessException e) {
e.printStackTrace();
}
While this code works fine on my Android 8.0 test system, it doesn't work on Android 4.0. The error is:
Could not find method java.lang.ReflectiveOperationException.printStackTrace
After some research I found out that ReflectiveOperationException is not available before Java 7 and so, apparently, Android 4.0 does not support Java 7.
This makes me wonder: Is there an overview which clearly shows which Android versions come with which Java version? e.g. how can I find out the first Android version that supports Java 7? And how can I find out the first Android version that supports Java 8?
This really must be easy to find but I'm just failing to see it. Googling always leads to results in which people are asking about the Java versions supported by Android Studio, not by Android itself.
So, can anybody please shed some light onto this? I know it must be somewhere really obvious, but I don't seem to find it...
and so, apparently, Android 4.0 does not support Java 7.
By your definition, Android does not support any version of Java. The java and javax classes in the Android SDK do not exactly match any version of Java, whether a numerical version (e.g., 6, 7, 8) or whatever you want to consider Java SE/EE/ME to be.
Is there an overview which clearly shows which Android versions come with which Java version
In terms of language features (e.g., lambda expressions), quoting the documentation:
Android Studio 3.0 and later supports all Java 7 language features and a subset of Java 8 language features that vary by platform version
Here, "Android Studio" is really referring to the build tools that compile your source code and create the Dalvik bytecode. Current tools can support all Java 7 and a few Java 8 features on all versions of Android. Additional Java 8 features are only available on API Level 24+, usually because they rely upon certain classes that were only added to the Android SDK at that point.
But your concern seems to be with classes and methods, in which case there is no simple mapping of any Java version to any Android version.
Moreover, you are using reflection to hack into framework classes, which means your results will not only vary by Android version but by device model, as device manufacturers can and do change the implementation of framework classes.
From the "Supporting Older Versions" AOSP documentation found at https://source.android.com/setup/build/older-versions#jdk:
Supported versions
Android 7.0 (Nougat) – Android 8.0 (Oreo):
Ubuntu: OpenJDK 8
Mac OS X: JDK 8u45 or higher
Android 5.x (Lollipop) – Android 6.0 (Marshmallow):
Ubuntu: OpenJDK 7
Mac OS X: jdk-7u71-macosx-x64.dmg
Android 2.3.x (Gingerbread) – Android 4.4.x (KitKat):
Ubuntu: Java JDK 6
Mac OS X: Java JDK 6
Android 1.5 (Cupcake) – Android 2.2.x (Froyo):
Ubuntu: Java JDK 5
The documentation does not presently (Feb 2022) make any correlation between Android >=9.0 and JDK (that I could find); I suspect this has been overlooked since it does not appear that the setup documentation has been thoroughly updated since sometime prior to the Ubuntu 20.04 LTS release. It does mention that the latest master branch (Android 12.0.0_r32) comes with a prebuilts folder that has the necessary JDK in it.
I am in the process of updating my Android studio, Android build tools, gradle version and JDK version. Trying to switch to JDK 1.8 I am wondering why the list in the Android Studio dropdowns for "Target compatibility" and "Source compatibilty" (in the module settings) only contain the values 1.6 and 1.7. Does this mean I forgot to install/update anything or forgot to change some path?
I know I can enter 1.8 manually, but the question is whether the missing 1.8 value means my setup might be incorrect?
Source and target compatibility has nothing to do with installed JDK. Your source code will still be compiled to Java 6/7/8 byte code which is used by Android. (Someone in comments, please point out technical inaccuracies, thanks.)
Source and target compatibility affects language constructs you can use in source code. E.g.
when targeting Java 6 you can't use the diamond operator,
when targeting Java 7 you can't use lambdas, etc.
Android Studio 3.0 and accompanying build plugin for Gradle (currently in development) will support Java 8 syntax out-of-the-box. Until then you could use retrolambda. Or straight up switch to Kotlin.
And of course then you'll need at least JDK 8 to target Java 8.
I am a new comer to the android world and with a .NET background. I am trying to install the Android Studio but I am having a mismatch on Android.com about the JDK version required for developing Android applications.
From the SDK web page it states that JDK 6 is required (under system requirements section). Jim Wilson also insist in his course on Pluralsight (which is quite new, from last May) that using version 7 with the Android SDK will create a lot of headache and makes it clear to only use JDK 6.
Although in the Android studio page (Under installing step 2) they explain how to set an environment variable indicating the correct JDK location. In here they use a path of JDK 7
Select Start menu > Computer > System Properties > Advanced System Properties. Then open Advanced tab > Environment Variables and add a new system variable JAVA_HOME that points to your JDK folder, for example C:\Program Files\Java\jdk1.7.0_21.
I am pretty sure both the ADT & Eclipse bundle and the Android Studio bundle are using the same SDK but now I am confused about which JDK version I need to install. My sole purpose is to avoid problems as much as possible while getting my first steps into the Android development.
Disclaimer: I am not related by any mean to Pluralsight. I am just a normal user following the courses.
Answer Clarification - Android Studio supports JDK8
The following is an answer to the question "What version of Java does Android support?" which is different from "What version of Java can I use to run Android Studio?" which is I believe what was actually being asked. For those looking to answer the 2nd question, you might find Using Android Studio with Java 1.7 helpful.
Also: See http://developer.android.com/sdk/index.html#latest for Android Studio system requirements. JDK8 is actually a requirement for PC and linux (as of 5/14/16).
Java 8 update (3/19/14)
Because I'd assume this question will start popping up soon with the release yesterday: As of right now, there's no set date for when Android will support Java 8.
Here's a discussion over at /androiddev - http://www.reddit.com/r/androiddev/comments/22mh0r/does_android_have_any_plans_for_java_8/
If you really want lambda support, you can checkout Retrolambda - https://github.com/evant/gradle-retrolambda. I've never used it, but it seems fairly promising.
Another Update: Android added Java 7 support
Android now supports Java 7 (minus try-with-resource feature). You can read more about the Java 7 features here: https://stackoverflow.com/a/13550632/413254. If you're using gradle, you can add the following in your build.gradle:
android {
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_7
targetCompatibility JavaVersion.VERSION_1_7
}
}
Older response
I'm using Java 7 with Android Studio without any problems (OS X - 10.8.4). You need to make sure you drop the project language level down to 6.0 though. See the screenshot below.
What tehawtness said below makes sense, too. If they're suggesting JDK 6, it makes sense to just go with JDK 6. Either way will be fine.
Update: See this SO post -- https://stackoverflow.com/a/9567402/413254
Normally, I would go with what the documentation says but if the instructor explicitly said to stick with JDK 6, I'd use JDK 6 because you would want your development environment to be as close as possible to the instructors. It would suck if you ran into an issue and having the thought in the back of your head that maybe it's because you're on JDK 7 that you're having the issue. Btw, I haven't touched Android recently but I personally never ran into issues when I was on JDK 7 but mind you, I only code Android apps casually.
Try not to use JDK versions higher than the ones supported. I've actually ran into a very ambiguous problem a few months ago.
I had a jar library of my own that I compiled with JDK 8, and I was using it in my assignment. It was giving me some kind of preDexDebug error every time I tried running it. Eventually after hours of trying to decipher the error logs I finally had an idea of what was wrong. I checked the system requirements, changed compilers from 8 to 7, and it worked. Looks like putting my jar into a library cost me a few hours rather than save it...
Android Studio now comes bundled with OpenJDK 8 . Legacy projects can still use JDK7 or JDK8
Reference:
https://developer.android.com/studio/releases/index.html
Just wondering if anyone has tried using new Java 7 language features with Android?
I know that Android reads the bytecode that Java spits out and turns it to dex. So I guess my question is can it understand the bytecode of Java 7?
If you are using Android Studio, the Java 7 language should be enabled automatically without any patches. Try-with-resource requires API Level 19+, and NIO 2.0 stuff are missing.
If you can't use Java 7 features, see #Nuno's answer on how to edit your build.gradle.
The following is for historical interest only.
A small part of Java 7 can certainly be used with Android (note: I have only tested on 4.1).
First of all, you could not use Eclipse's ADT because it is hard-coded that only Java compiler 1.5 and 1.6 are compliant. You could recompile ADT but I find there is no simple way to do that aside from recompiling the whole Android together.
But you don't need to use Eclipse. For instance, Android Studio 0.3.2, IntelliJ IDEA CE and other javac-based IDEs supports compiling to Android and you could set the compliance even up to Java 8 with:
File → Project Structure → Modules → (pick the module at the 2nd pane) → Language level → (choose "7.0 - Diamonds, ARM, multi-catch, etc.")
This only allows Java 7 language features, and you can hardly benefit from anything since a half of improvement also comes from the library. Features you could use are those which do not depend on the library:
Diamond operator (<>)
String switch
Multiple-catch (catch (Exc1 | Exc2 e))
Underscore in number literals (1_234_567)
Binary literals (0b1110111)
And these features cannot be used yet:
The try-with-resources statement — because it requires the non-existing interface "java.lang.AutoCloseable" (this can be used publicly in 4.4+)
The #SafeVarargs annotation — because "java.lang.SafeVarargs" does not exist
... "yet" :) It turns out that, although Android's library is targeting for 1.6, the Android source does contain interfaces like AutoCloseable and traditional interfaces like Closeable does inherit from AutoCloseable (SafeVarargs is really missing, though). We could confirm its existence via reflection. They are hidden simply because the Javadoc has the #hide tag, which caused the "android.jar" not to include them.
There is already as existing question How do I build the Android SDK with hidden and internal APIs available? on how to get those methods back. You just need to replace the existing "android.jar" reference of the current Platform with our customized one, then many of the Java 7 APIs will become available (the procedure is similar to that in Eclipse. Check Project Structure → SDKs.)
In additional to AutoCloseable, (only) the following Java 7 library features are also revealed:
Exception chaining constructors in ConcurrentModificationException, LinkageError and AssertionError
The static .compare() methods for primitives: Boolean.compare(), Byte.compare(), Short.compare(), Character.compare(), Integer.compare(), Long.compare().
Currency: .getAvailableCurrencies(), .getDisplayName() (but without .getNumericCode())
BitSet: .previousSetBit(), .previousClearBit(), .valueOf(), .toLongArray(), .toByteArray()
Collections: .emptyEnumeration(), .emptyIterator(), .emptyListIterator()
AutoCloseable
Throwable: .addSuppressed(), .getSuppressed(), and the 4-argument constructor
Character: .compare(), .isSurrogate(), .getName(), .highSurrogate(), .lowSurrogate(), .isBmpCodePoint() (but without .isAlphabetic() and .isIdeographic())
System: .lineSeparator() (undocumented?)
java.lang.reflect.Modifier: .classModifiers(), .constructorModifiers(), .fieldModifiers(), .interfaceModifiers(), .methodModifiers()
NetworkInterface: .getIndex(), .getByIndex()
InetSocketAddress: .getHostString()
InetAddress: .getLoopbackAddress()
Logger: .getGlobal()
ConcurrentLinkedDeque
AbstractQueuedSynchronizer: .hasQueuedPredecessors()
DeflaterOutputStream: the 3 constructors with "syncFlush".
Deflater: .NO_FLUSH, .SYNC_FLUSH, .FULL_FLUSH, .deflate() with 4 arguments
That's basically all. In particular, NIO 2.0 does not exist, and Arrays.asList is still not #SafeVarargs.
EDIT: At the time this was written, the latest release was Android 9 and Eclipse Indigo. Thing have changed since then.
Practical answer
Yes, I have tried. But this is not a great test as the compatibility was limited to level 6 with no way (no simple way at least) to really use java 7:
First I installed a JDK7 on a machine that had no other JDK installed - Eclipse and Android are not installed either:
Then I installed a brand new Eclipse Indigo and checked it was actually using the JDK 7 (well, as this is the only one and as this is the one I've selected I would have been surprised)
Then I installed the latest version of the Android SDK (EDIT: Honeycomb, API13, at the time this post was written). It found my JDK 7 and installed properly. The same for ADT.
But I had a surprise when trying to compile and run a Hello Word Android app. The compatibility was set to Java 6 with no way to force it to Java 7:
I tried with a non-Android project, a regular Java one, and I had the explanation. The compatibility level seems to be limited by Eclipse (see the message at bottom of the following image):
So I had Hello World working, and also other apps, more complicated and using SQLite, Listview, Sensor and Camera, but this only proves that the compatibility handling of Java 7 seems to be well done and working with Android.
So, did someone try with the good old Ant, to bypass the Eclipse limitation seen above?
Theroetical answer
Anyway, the SDK is designed to be used with Java 5 or 6, as explained here.
We may have something working with Java 7, but it would be working "by accident". The building of the DEX may work properly or not, and once the DEX built, it may work or not. This because using a non-qualified JDK gives unpredictable results by definition.
Even if someone has succesfully built an Android app under plain Java 7, this does not qualify the JDK. The same process applied to another application may fail, or the resulting application may have bugs tied to the use of that JDK. Not recommended.
For those who are involved on webapps development, this exactly the same as deploying a web application built under Java 5 or 6 under an application server qualified for Java 4 only (let's say Weblogic 8 for example). This may work, but this is not something that can be recommended for other purposes than trying.
Quote from dalvikvm.com:
dx, included in the Android SDK, transforms the Java Class files of Java classes compiled by a regular Java compiler into another class file format (the .dex format)
That means, the .java source file does not matter, it's only the .class bytecode.
As far as I know, only invokedynamic was added to the JVM bytecode in Java 7, the rest is compatible to Java 6. The Java language itself does not use invokedynamic. Other new features, like the switch statement using Strings or the multi-catch are just syntatic sugar and did not require byte code changes. For example, the multi-catch just copies the catch-block for each possible exception.
The only problem should be that the new classes introduced in Java 7 are missing in Android, like AutoCloseable, so I'm not sure if you can use the try-with-resources feature (somebody tried it?).
Any comments on that? Am I missing something?
As of the Android SDK v15, along with Eclipse 3.7.1, Java 7 is not supported for Android development. Setting the source compatibility to 1.7 mandates setting the generated .class file compatibility to 1.7, which leads to the following error by the Android compiler:
Android requires compiler compliance level 5.0 or 6.0. Found '1.7' instead. Please use Android Tools > Fix Project Properties.
To expand on the above answer by #KennyTM, if you are targeting 4.0.3 and above (minSdkVersion=15), you can use the hidden APIs by adding a few classes to your target's SDK android.jar.
Once you do this, you can use try-with-resources on any Closeable, as well as implement AutoCloseable in your own classes.
I've made a zip containing sources and binaries of all the classes that needed to be modified in android.jar to make these APIs available. You just need to unpack it and add the binaries to your android-sdk/platforms/android-NN/android.jar
You can download it from here: http://db.tt/kLxAYWbr
Also of note is that, in the past couple of months, Elliott Hughes has made a few commits to the Android tree: finished off AutoCloseable, added SafeVarargs, unhidden various APIs, fixed Throwable's protected constructor and added support for version 51 class files in dx. So, there is finally some progress going on.
Edit (April 2014):
With the release of SDK 19 it is no longer necessary to patch android.jar with the additional APIs.
The best method to use try-with-resources in Android Studio for an app that targets 4.0.3 and above (minSdkVersion=15) is add the following compileOptions to your build.gradle:
android {
compileSdkVersion 19
buildToolsVersion '19.0.3'
defaultConfig {
minSdkVersion 15
targetSdkVersion 19
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_7
targetCompatibility JavaVersion.VERSION_1_7
}
}
Android Studio will complain that try-with-resources can't be used with this API level, but my experience is that it can. The project will build and run without issue on devices with 4.0.3 and above. I've experienced no issues with this, with an app that has been installed into 500k+ devices.
To ignore this warning, add the following to your lint.xml:
<issue id="NewApi">
<ignore regexp="Try-with-resources requires API level 19"/>
</issue>
It seems that getting this to work with pure ant is a bit of a kludge.
But it worked for me: http://www.informit.com/articles/article.aspx?p=1966024
In order to use Java 7 features in code build by Android's ant based build system, simply put the following in your custom_rules.xml in your projects root directory:
custom_rules.xml:
<project name="custom_android_rules">
<property name="java.target" value="1.7" />
<property name="java.source" value="1.7" />
</project>
Some people might be interested in this git project I've found, that seems to allow to run Java 7 on android.
https://github.com/yareally/Java7-on-Android
However too much of a risk if I add this in the current project I work on. So I'll wait until Google to officially support Java 7.