I'm wondering why doesn't Google ditch Java entirely and create something like XobotOS[1]. I know it wouldn't be a popular move but at least the devs will get a decent language to use (C#) and users will have a better performing OS[2]
I've wondered the same. Apple did a good move with Swift. Not sure why Google doesn't invest in their own language. Would be really nice to see a full on native and new language for Android by Google.
I'm wondering why this is downvoted. I would love to have an official Android language that is better suited to mobile than Java. Instead of hacking away at the JVM (or cloning it) to make it work properly on CPU/memory/power-limited devices.
J2ME never had near enough functionality for the apps to do anything very interesting. I do not recall a single J2ME app apart from Opera Mini which was worth using. All the good (by the standards of that time) apps were non-J2ME, at least on Symbian and Windows Mobile.
So even though it was fast enough, I wouldn't compare it to Java as it exists for Android now.
You need to go to Japan more often. I worked quite a lot with NTT DoCoMo and they had amazingly useful games and apps. Everything from a bank machine locator to physical vending machine purchases (with NFC).
They had motion sensor support in J2ME devices that they used mostly for fishing/golf games circa 2003-2004 (don't hold me at the dates my memory is the gray equivalent of Swiss cheese).
Anyway, J2ME had a lot of levels CDC was pretty much Android equivalent but it didn't have GUI API on top of it because Sun disallowed MIDP on top of CDC and didn't offer anything other than AGUI which nobody used... I can go into endless details here but generally, the reason J2ME failed was that it was a tool built in 1999 with a single moderate update in 2004 and nothing else!
The only thing that hindered J2ME on my old flip phone from 2006 was the carrier disabling all the interesting APIs. If Android had been based on J2ME and put control in the hands of users instead of carriers, it would be a much better system IMO, especially in terms of security.
> Not sure why Google doesn't invest in their own language.
Has no one in this branch of the thread ever heard of a little thing called Go?
You could also bring up Dart, although Google's apparent commitment (and my own interest) in that is far lower.
Work IS coming along on being able to write full Android apps entirely in other Google-originated languages. You might reasonably ask why they're not pouring dramatically more resources into accelerating that process. I don't know, but I can only speculate that the enormous scale of the existing Android ecosystem makes it risky to send the wrong signal prematurely.
If we're looking at a matter of years before full featured Android apps in pure Go is feasible, then you probably wouldn't want to talk that up TODAY. The perception would be that Java on Android is dead, and major new app development for Android would halt.
Go isn't suitable for the kind of mission critical and memory constrained apps that Android requires.
The absence of generics and exceptions makes Go a step backward compared to Java. It was also absolutely not designed for Android (its driving design goal was to compile fast).
Dart's type system is also much weaker than Java so it would be a step back as well.
Right now, Google doesn't have any in-house credible alternative language to Java.
Interestingly, Kotlin is growing on Android without Google having anything to do.
Dart is a pretty nice language, and practically speaking I don't think it's "weaker" (optionally typed) system is a concern. The vast majority of Dart libraries are typed, giving you all of the benefits (compile time type checking, runtime type checks, intellisense, etc.)
Check out the flutter project (http://flutter.io) for a hint of what Dart on Android and iOS looks like.
I've been working professionally with Java for 19 years. I've only worked "semi-professionally" with Go for 3 or 4 years, as a secondary language for a few niche applications at work and some personal projects at home. So I may or may not be the most qualified person in the world to represent Go here.
All that being said, the longer I work with Go, the less I really see its lack of generics as a significant shortcoming. Go simply doesn't emphasize object-orientation to the same degree as idiomatic Java. Given the choice, I'd prefer to have that tool available than not have it. However, I haven't yet personally run across a real-world scenario in which lack of generics was an actual big deal.
I am QUITE comfortable in asserting that Go's error handling exceeds that of Java's, not lags it. The "try-catch" concept is still there (as "panic-recover"), albeit discouraged in many of the cases that an experienced Java developer would want to use it. The convention of having every function return a possible error struct, and the compiler's insistence that you do something with that that returned struct, pushes Go developers into a much more disciplined mindset of approaching exception handling.
The two points above are subjective, of course. Reasonable people could argue them either way. The third response is a bit more objective. Regarding the notion that Go is "absolutely not designed for Android" and its memory constraints, I must point out that neither is Java! As a matter of the Java language's syntactical suitability, the obvious observation is that Java PRE-DATES Android by more than 12 years. Considering the laws of physics and space-time, it was clearly not designed by James Gosling with Google's OS in mind. Secondly, the memory constraints of carrying a built-in garbage collection runtime also apply to Java. The only difference is a matter of maturity, and the level of resources that have gone into developing a custom Java solution for Android. There's no reason why Google couldn't do the some with Go (or almost any other language), and given Go's comparative simplicity it would probably take far less time to get there.
Sure, you can assign returned errors to the underscore black hole and move on. However, that is still consciously and deliberately "doing something" with it.
It is glaringly obvious in a code review that you have done this. Also, although I'm not personally familiar with any Go tools similar to PMD or Sonar in the Java world... it would be fairly easy to write a static analyzer that could scan code, recognize this pattern, and report on it (along with other code smells) in an automated manner.
Nevertheless, idiomatic Go functions return an error structure, and you must do something with that error structure. There is no ambiguity as to where the error structure came from.
Contrast that with Java's model, which is much more (pardon the expression) catch-all. There is endless debate on how wide or narrow to make your try-catch blocks, when to handle an exception locally vs. throwing it back to the caller, etc.
It is very common to deal with bugs that stem from silently "swallowing" exceptions at an inappropriately low level. It is just as common to see patterns where nearly all methods throw nearly everything without a catch at all... and there's a monster try-catch block at the top level catching the base "Exception" class.
Worst of all, there are entire classes of runtime exceptions which are NOT declared as throwable in the method's signature. The compiler has no means of insisting that you do anything about those, because the compiler doesn't know which ones are possible during a given method call. Go's error handling model is safer and better thought-out in that regard.
When you think about issues stemming from Java's handling of checked vs. unchecked exception types, it makes a lot more sense why Go went in the direction it did. Also, why Go application developers are discouraged from using "panic-recover"... and why Go library developers almost always recover from panics and create error structs for passing back upstream.
Adding Go to the official SDK and providing official bindings.
Go team is just doing what everyone else does, by making use of the NDK and writing Go wrappers manually on top of JNI calls to the official Android APIs.
So far there have been zero interest from Android team to support anything other than Java. Even the C and C++ support is just to write performance code to be consumed from Java, not to write full blown apps.
They were never asked by Google to make a language, and as far as I've always known (feel free to provide a link that says otherwise) Google employees are allowed to spend some of their work time to work on side projects, I've never heard of Google only paying them to work on Go and only Go, please feel free to correct me on this as it's news to me.
the comparison between dalvik & xamarin is not that interesting anymore (it was in 2012 though). It would be interesting to remake this bench.
Why doesn't Google ditch java ?
Because such a switch would be very costly and there are many more cost effective ways to improve the platform (like for example databinding).
I also doubt that Google would choose a language controlled by Microsoft, they had enough trouble with the java lawsuit..
if the rumors of the merge of Android & ChromeOS are true, maybe this will be accompanied with with a big framework change ?
It will depend on how this plan materialize exactly but that would be the right time for that.
[1]: https://github.com/xamarin/XobotOS [2]: https://blog.xamarin.com/android-in-c-sharp/