The law of unintended consquences
Oracle: Grrrr! Stop using Java without paying us or we'll sue you!
Google: - OK, we'll stop using Java.
Oracle: - Uh, wait a minute, let me rephrase that!
Java on Android is dying, and before long will be dominated by Kotlin, or so says a selective slice of developer data. Realm, which offers a real-time database popular among mobile application makers, has crunched the numbers from its pool or 100,000 or so active developers. The company on Tuesday published its findings, a …
"The law of unintended consquences
Oracle: Grrrr! Stop using Java without paying us or we'll sue you!
Google: - OK, we'll stop using Java.
Oracle: - Uh, wait a minute, let me rephrase that!"
This is entirely Oracle's fault for being overly litigious in respect of Java APIs and they only have themselves to blame. The good thing about Kotlin is that it's covered by an Apache 2 free software licence and Oracle's not involved either so the potential for legal actions is much reduced.
I'm pretty sure the vast majority of Android apps out there are written in either C# (Xamarin/Unity) or C++ (Unreal, Lumberyard, et al.), with the bare minimum of Java required to get the damn thing to work.
Nobody with any kind of desire to support other platforms would write a whole app in Java.
Google just just quietly introduce a decent C API (they already a half-arsed one for some systems) and just admit that Java is nothing more than a second-class wrapper that should be avoided at all costs for future apps.
Based on what I've read about the market rather than projecting my own prejudices:
- Java is the most widely used language for Android development. It is/was the officially supported general purpose language and the official documentation and support assumed you were using it.
- C++ is used for some games, particularly ones that were meant to be cross-platform with Apple phones. However, many of these applications would do the heavy duty logic and control in C++ but use Java for the UI.
- C# is used for some games, particularly games that are written for the Unity game engine. The main reason for using it was familiarity existing game programmers had. There's a limited market for this though, as many new game developers started on mobile platforms and didn't carry PC baggage with them. There is also some use of C# for corporate applications which are developed internally by people whose background is C# only. That's also a limited market due to a lot of this work being outsourced to consultants.
- Various other languages - these come and go and are difficult to categorise.
There are some news stories that compare market share for cross platform development, but since most mobile development isn't cross platform they don't actually tell you much that is useful.
So it appears that Java has been the default language that Android developers use. Anything else is limited to specific market niches. If you work in a specific niche however, you may find a particular niche language widely used there.
The main problem with using one of the niche languages is that things like documentation, support, and bug fixes are harder to come by than when using the "official" language.
Kotlin is supposed to take over from Java as the main default language. I haven't used it so I can't comment on its prospects there.
I'm not projecting my prejudices. I base my comments on my own experiences.
Almost every Android developer uses at least a little bit of Java. You really have no choice in the matter. Java is the defacto language for Android.
But... you put a bunch of Android developers in a room, and I'll bet each and every one of them will put their hands up when asked whether they use Java, despite the fact that a large number of them problem only know the bare minimum required to get their app integrated. I'd probably put my hand up, because I do actually know Java and have used it in the past. Do I use it today for our Android apps? Not really. I step in and out of it in the debugger from time to time, but that's about it.
So on that basis, yes, Java is the most used language, because you have no choice.
My point was, however, that the vast majority of developers use the absolute minimum, and probably quite a lot of those only use the boilerplate wrappers that their platform of choice generates for them.
We have a UI layer written in Java for our Android apps, the same way we have a Swift layer for our iOS, macOS, and tvOS apps. But they really are very thin layers around our cross platform C++ engine. We'd have been crazy to choose Java as our main development language. As it happens we do call into some non-UI Java libraries on Android today (MediaDecoder, et al.), but we'll be switching those out and calling the C based OpenML AL APIs that Android exposes directly at some point in the future. Basically to get rid of the Java overhead.
With that all said, you might be right. Java could well be the most popular language for Android development. But I honestly doubt it. In 2015 Unity was claiming they had 4.5 million registered developers. (And last year they had 5 billion "Made with Unity" downloads in Q3 alone.) Xamarin has 1.4m active developers as of April this year. Unreal has over 2 million. These aren't small numbers. Especially when you consider some estimates put the total number of Android developers at only around 6 million in total.
Oh, and no C++ game engine uses Java for its UI. ;)
Java could well be the most popular language for Android development.
For some values of "popular."
"Popular" meaning "used by most apps, even if only as a wrapper around the UI and with the bulk of the work being done in a less shitty language" - almost certainly.
"Popular" meaning "used as the only language to write most apps" - probably not.
"Popular" meaning that most app writers think "This is a wonderful language, I love it, I can't get enough of it, I even dream in it" - no fucking way.
Many people enjoy drinking beer but do not particularly enjoy urinating, even though one invariably leads to the other and are thus equally "popular" as the term is used in the original post. Few people, in my experience, say "Fancy going out for a piss?"
Popular does not equate to enjoyable unless one has freedom of choice in the matter. In this case, you have no choice but to use a little Java in wrappers even if you hate having to do so.
Finally, I can shake off that crusty, old, stale, waffly language Java.
Java's problems started with Sun's demise, the language has lagged behind other languages such as C#.
I've not used Kotlin in anger yet, but it looks very much like Swift and I look forward to coding with it*
* I might give it a few months to allow StackOverflow to fill up, so I can copy and paste ;)
"Java's problems started with Sun's demise"
Surely they started with Java's existence?! It has continually had stratospheric vulnerability levels. Coexistence and updates are a nightmare. It doesn't perform well versus the competition and has major garbage collection issues. It's just a total pos and it's demise can't come fast enough!
I wonder if it matters any more, in the sense that it's been a long time since I heard of a significant use of a computing platform that was only possible because the developer(s) picked a specific language. (And for sticklers, let's ignore the obvious response that any Turing-complete language can do anything...)
I could write something like Angry Birds in C, or Java, or C#, and they would all be painful and pleasant in their own unique ways. Is Kotlin essentially just a better (slightly more productive) version of that? Or is it a massively more productive version (cf Fortran vs assembler circa 1960)? Or does it enable me to do things that are practically impossible in the others?
Kotlin is Java with some of the sharp edges removed. For example it's null safe and auto-casts.
In return you've got to put up with its half-baked functional model, which is like Scala but nowhere near as expressive or flexible. This may not be a bad thing as it means people can't just implement a DSL that functions purely on implicits and black magic.
But yeah, hardly a sea-change.
The thing you've got to remember though is most Android "Java" developers were until very, very recently stuck on a positively ancient version of the language (i.e. 6), which is painful to work in and is missing many of the newer innovations of 7/8/9. So for an Android Java dev Kotlin must look like mana from heaven.
You'd be surprised. First off anything that lives in a niche, tied to a vendor product is almost certainly a closed source language. This is especially the case in the enterprise analytics space. Think of your Matlabs, your SASes, your SQLs, your godforsaken crosses between SQL and procedural. Then you've got your commercial C/C++ variants (hello MSVC!). Let's not even get started on the likes of Apex.
Closed source programming: surprisingly common.
"What would a closed source language be?"
In some ways, Java. but only because Oracle owns everything about it, and dictates what people can do to it. But there's OpenJDK, so it's not entirely "closed". You do not have to use Oracle's JVM or JDK.
That being said, the only thing I really hate about Java is the LACK of "unsigned integer" types. Yeah. They arrogantly leave that out, deliberately. It makes certain things *difficult* in Java. but when you're doing device control, or reading binary data from a device with 64-bit unsigned integers and bit flags to go with them, it becomes a bit tedious, ya know?
yeah, rather short-sighted of them, isn't it?
I only use Java for 'droid anyway, and only because it's easier at the moment...
I'd argue that most of the bloat in Java 8 comes from traditions of anti-patterns and bad/buggy Checkstyle rules. What's really being discarded are bloated coding patterns. I wouldn't be surprised if Kotlin's helpful attempts to further reduce bloat are undone by new anti-patterns.
In scanned through the Kotlin documentation and noticed that it's moving more towards immutable objects and the elimination of primitives. That's a nice option, but enforcing that in CPU sensitive code destroys performance. Making tight processing loops 100x to 1000x slower on a mobile device is a bad idea.
I thought Kotlin had a very heavy reliance on the underlying core Java class libraries, at least that's what I heard/read a while back. If so then sadly Java and Oracle are going nowhere, all you get is less need to learn direct Java coding but you will still need to know what's happening under the hood.
Biting the hand that feeds IT © 1998–2019