I have a library which uses the Apache Commons Text library.
A test suite for my library runs fine in JRE. However, when I use the library in an Android app and try to run it on an old device (running Android 4.4.4 aka KitKat), it crashes with a NoClassDefFoundError. The offending call seems to be StringSubstitutor.replace().
What is the issue here?
As per the release history, Apache Commons Text requires Java 8 since version 1.4 (released in mid-2018), which is not fully supported on older Android versions.
Specifically, one of the missing classes is java.util.Base64, which was introduced with Java 8. On Android it requires API 26 (Android 8) or higher.
If you need to support Android back to version 7, going back to Apache Commons Text version 1.3 works, as long as you are not relying on any of the features introduced in later versions. (StringSubstitutor.replace() was already available back then.)
If you decide to go down that route, bear in mind that you will be stuck with a library that (as of January 2023) is almost five years old, to support an OS that is at least six years old and for which security updates were discontinued more than three years ago.
Related
My android studio project uses the embedded JDK which is version 8 by default im wondering will my app still run on android 4.0 and 5.0 devices ?
The app will definitely run with JDK 8 run it.
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.
Android Studio provides built-in support for using certain Java 8 language features and third-party libraries that use them.
Note:
When developing apps for Android, using Java 8 language features is
optional. You can keep your project's source and target compatibility
values set to Java 7, but you still need to compile using JDK 8.
And about your minSDK comment "whats your preferred minSDK? if you start with API 19 you have a rate of 95%"->
minSdk is required to set the minimum api level run environment(android OS version) to the application. If you choose minSdk the minimum possible you can target max number of devices.
If you want to use JDK8 to compile your Android app there is no problem with it, you can easily set compatibility to Java 6/7 and there won't be any issues.
If you want to use Java 8 language features it all depends on the mindSdkVersion that you have set up. You can freely use:
- lambda expressions
- method references
- default and static methods in interfaces
- repeating annotations
Java 8 API is available from API level 24 unfortunately in your case you won't be able to use any Stream API and such.
For more information please check:
https://developer.android.com/studio/write/java8-support
I would like to use the OpenNTF Domino API but to me it is not clear which version I can use?
The version of the extension library on the Domino server is 9.0.1.v00_00_20151122-0905 (upgrade pack 1).
If you're using Domino 9.0.1 Feature Pack 8, then 4.0.0 is the way to go. Otherwise, 3.2.1 is the right one.
The plan is for 3.2.x to get critical fixes (which is what 3.2.1 itself was over 3.2.0) but otherwise remain as-is, while future development will happen on the 4.x+ Java 8 path.
The version of ODA will depend primarily on the Domino server version. It sounds like you're running Domino 8.5.3 and we've not specifically developed against that version. There was a lot of new functionality added in 9.0, specifically around NoteCollections, which is spread throughout the API. I did compile a version some years ago for 8.5.3, but it was never heavily tested or officially released. The server in question was upgraded to 9.0 before the project went live, so I'm not sure if I even have that version any more.
Version 4.0.0 is the first specifically compiled for 9.0.1 FP8 and will not work on previous versions. That's because it includes the new core Domino APIs (encryption, ID Vault etc) added with FP8. It's not currently compiled for Java 8, but work on that has already begun in the develop branch.
Version 3.2.1 is the recommended version for 9.0.1 up to FP7. It will still work on FP8, but only if there is no intention of using the new Domino APIs added with FP8. It will work with the base Extension Library as long as the Graph API REST functionality isn't required (not a regular requirement at this time), for which ExtLib 9.0.1_v00_17 is required. That's because additional hooks were added to the core Domino REST service functionality in ExtLib.
For any general discussion about ODA, there is an OpenNTF Domino API channel in the OpenNTF Slack. The OpenNTF Slack team can be joined from the main OpenNTF website home page.
I am using Netty for a while now and could never solve this question. One can download four different versions. Three of them are actively getting developed.
3.x
4.0.x
4.1.x
5.x
As far as I understand 3.x is for JRE 1.5 and everything else for JREs greater than that. I am using 4.0.28 because it is the stable and recommended version. But what exactly is the difference or goal of the other versions?
I could not find any information about this on their website.
EDIT: I see close votes coming so I'd like to clarify: I'm not looking for someone who lists me all the differences in the code of the versions. But there has to be some sort of objective or purpose for the 4.1.x and 5.x versions.
3.x is deprecated. We maintain it because some users still use it widely.
4.0 is the current stable version. When in doubt, use this version.
4.1 is a backward compatible version of 4.0. It adds some cool new features like HTTP/2 and asynchronous DNS resolver. So, 4.1 is the version you might want to try when your application already runs on top of 4.0 and you wanna try the new features.
5.0 is a backward incompatible version. However, it's not like a rewrite we did for 4.0 vs 3.x. However, we did fix some API design flaws. You'll need to make some changes in your code to make your Netty 4 application run on Netty 5, but it's not like porting Netty 3 application to Netty 4 application. Eventually, 4.x will be deprecated and 5.0 will be a stable version.
It should be noticed that 5.0 had been revoked in Nov 2015, 4.1 is the newest stable version now.
If you want to know what are all new (and noteworthy changes) between these versions, you can visit these links:
3.x -> 4.0
4.0 -> 4.1
4.x -> 5.0
Oracle has announced that they stop the official updates for JRE 7 and JDK 7.
As much as I know, Google doesn't say anything about JDK 8, I guess the recommended version is JDK 7 for Android development.
Is JDK 8 officially supported for Android development?
The Google Android development page and, from there, the pre-requisites page list JDK7 as a requirement.
This has nothing to do with Oracle's JRE since the code made during Android development is never meant to run on that JRE - it's supposed to be turned into Dalvik bytecode and run under Android.
So the security concerns of Oracle's JRE are not really at issue here. Google supports JDK7 (insomuch as it pertains to Android development) so that's what you should be using, pending a clear statement of intent from Google.
It looks like Google doesn't officially support the JDK 8 for Android development. See paxdiablo's answer.
But let me add some thoughts.
I wanted to try using the JDK 8 anyway. So I downloaded and installed it, and used it (and Apache Ant) to build a simple Android app.
The app doesn't use any features which are new to Java 8, such as lambdas. In addition, Ant passed a parameter to javac asking it to emit bytecode compatible with older JREs.
The app compiled fine.
The app requires that I root my phone before running it. I haven't done so yet, and haven't tested the app yet either.
Please ping me with a comment in a few weeks. Ask me to update this answer and to let you know whether or not the app worked.
What Android API version would you choose to begin developing a new Java application?
Recently I got a used smartphone running Android 2.2.1. Since I never experimentend with mobile development, I decided to use it as an occasion to try to develop a new app for Android.
I worked in Java from some year, and I feel comfortable with it, so since I already work as an independent software vendor I’ll try to sell the app on the Android market if I will be able to do a good one.
I don’t want to start developing with an outdated version of the API, so a I’m asking if starting my development and learning efforts using level 8 of the Android level API is the better choose to take, or if it would be better to use a newer version of the API.
I read why is Android API level 9 obsolete? and Which Android API to use? on S.O. about the same argument, but both the questions are pretty outdated now, and I think they left some question opened.
In particular, Jan Dragsbaek said in his answer:
You should always go for the lowest possible API to use. Simply
because the lower your API level is, the more users can you reach.
So looking at the current stats, you are able to reach 97.9% if you “dumb” yourself down to API level 7.
But why API level 9 is obsolete? One could not know for sure, but most likely because it had some major flaws.
Reading actual stats, this is the situation:
Platform Codename API-Lvl Distribution
Android 1.5 Cupcake 3 30,00%
Android 1.6 Donut 4 70,00%
Android 2.1 Eclair 7 550,00%
Android 2.2 Froyo 8 20,90%
Android 2.3 Gingerbread 9 0,50%
Android 2.3.2 -
Android 2.3.3 - 10 63,90%
Android 2.3.7 -
Android 3.0 Honeycomb 11 0,10%
Android 3.1 - 12 1%
Android 3.2 - 13 2,20%
Android 4.0 - Ice Cream Sandwich 14 0,50%
Android 4.0.2 -
Android 4.0.3 - 15 4,40%
Android 4.0.4
Total for Android 2.2 93,50%
Now the question is: What will I lose if I develop with level 8 of API in terms of features? And what do I gain in terms of stability or tool support?
EDIT:
I finally choose to use level 7 of the API, which offer me the features I really need to get started to experiment on my new phone. Eventually, when I think that app need some feature not available with the current level, then I will port the app to a next level of the API.
For now, I will try to follow Building a Custom Fancy ListView in Android and see if I'm missing something really useful from the beginning.
I think that you should look at your requirements too. Draw up the API's which is absolutely necessary for your app and narrow down to the minimum Android API level which you can use. Since it is correct that your outreach will be more if you make use of lower API levels.
Having said that, if you still feel uncomfortable with lower API level and find yourself restricted then you can infact use Android Support Libraries. Quoting from the description of the support library:
The Support Package includes static "support libraries" that you can add to your Android application in order to use APIs that are either not available for older platform versions or that offer "utility" APIs that aren't a part of the framework APIs. The goal is to simplify your development by offering more APIs that you can bundle with your application so you can worry less about platform versions.
Level 9 is obsolete because level 10 replaced it completely. Another way of saying that is that is Android 2.3.3 replaced Android 2.3, so now if you're aiming for 2.3 devices, you use the 2.3.3 API. Level 8 is not obsolete because there is not a similar API level to replace it (all the 2.2 updates were still level 8).
As for features lost, you can look at the list of all the new features in API 9 (API 10 doesn't really have any major new features but you can check it too on the same site). If you don't need any of those features, then no need to aim for 2.3.3. Same thing over again between 2.2 and 2.1; go with the lowest level that has the features you want, as you said. Speaking from experience, 2.1 provides everything you should need for regular use - internet, storage, graphics (although the advanced graphics get better as you go on), UI, etc.
You will neither gain nor loose nothing much.
Level 9 is obsolete as compared with level 10. Level 9 is GINGERBREAD and Level 10 is Gingerbread Maintenance Release 1 i.e. bug fixes.
Level 8 is 2.2 level 7 is 2.1 they are not obsolete, just old.