[Cthulhu_]

Never say never, that's what I thought about Apple and objective-C, and they just invented a new language for it.

True, it runs in the same runtime, but it does allow them to slowly move away from 20 years of history. Mind you, the obj-C runtime / Foundation isn't badly set up at all, I'd argue it's better than the Java SDK.

[pjmlp]

As the one that raised the Go support ticket for Android, back when I was still following Go I doubt it.

That ticket was raised before Go 1.0, so I very much doubt it.

[vetinari]

Go and Java stdlib have very different opinions about the basic types, used by every app (like strings or maps, heck, even about concepts what is a class and class hierarchies, or how the stack is supposed to look like).

So unless you want to wage a perpetual war at the border between your app and Android base libraries, forget Go, or about any language that does not run on JVM.

[V-2]

Without providing close to 100% interoperability, replacing Java with another language would be insane. All the open-source third party libraries for Android (and there's plenty, and many of them have become the de facto industry standard), all of that goes out of the window. I don't see how it could pan out

[nickpsecurity]

You make something that's easy for an automatic translation. Then you use that. It's how both AS/400 and OpenVMS kept binary compatibility on completely different hardware over time. The good news is there's a lot of clones of Java in CompSci and compilers of other languages targeted to JRE. Retargeting them to something similar wouldn't be hard. Recompiling bytecodes wouldn't be hard.

It's the high-level language and interfaces that would be hard. The real factor, though, is social given lock-in is in full effect here. Java was a bad, long-term bet given the Oracle acquisition.

[alirazaq]

So progress should be avoided if it means throwing away everything else?

I can see Android rolling this out across two major releases. The first adding support for a new VM or app language and the second removing Java. Time between those releases will give developers the chance to catch up.

I just think it's silly that you are opposed to throwing everything away. That is what got us in this mess to begin with. Android was supposed to be a simple transition for existing J2ME devs.

[V-2]

Ditching rich pre-existing ecosystem by itself certainly isn't progress. The greatest language without that ecosystem is like the shiniest OS with no apps. This includes communities, developers who've acquired enormous amounts of know-how by now... It would be extremely hard make this trade-off worth it. A tough call, and a multibillion dolar company will think more than twice before choosing that route. I know I would

"I just think it's silly that you are opposed to throwing everything away"

That may be, but I'm pretty sure Google wouldn't think so :)

[vetinari]

It took Apple 12 years to deprecate Carbon API. It is still being shipped for compatibility.

Nobody really throws away anything, that other people are depending on. Especially, if you are depending on their continued investment into your platform.

Otherwise, Windows Mobile to Windows Phone happens. Or Python2 to Python3 (how many years it is already taking?)

So two major releases is too optimistic. Especially in android world, where more than two major releases are used simultaneously.

[tomjen3]

If that is the level we are happy about you can already run with Kotlin today. Its not official Alphabet, but it is offical from the company that makes Android Studio and it is roughly to Java what Apples new language was to Objective-C.

Unfortunately that still means that there is no good way to write cross-platform mobile apps.

[Longhanks]

There is never a good way to write cross-platform apps. Cross-platform programs are always inferior to solutions specifically designed for a particular use case (e.g. touch input + mobile device, pen input + tablet device).

[tomjen3]

I agree there needs to be a platform specific input output layer, but assuming you are writing the same app on different devices there is always going to be a large core (essentially all the business logic, all models, all validation, all sync code) that is, or should be, the same on all platforms. It is that code I wanted to refer to.