Hacker News Reader

Comment by akadien | Hacker News Reader

Oracle should pay Google for using Java in Android and keeping the language somewhere around edge of hip and cool. I wonder how long it will be before Google flips to Go or JavaScript for Android.

View on HN

It will never happen.

In spite all of this, Android Team has given zero support for anything other than Java on Android, even for its own languages.

The NDK is anemic, because "In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need."

http://developer.android.com/tools/sdk/ndk/index.html

And the Go and Dart teams had to work on their own even for the NDK integration.

The results of their work aren't even described in any of the official Android documentation sites.

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.

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.

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.

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

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.

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.

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.

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 :)

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.

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).

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.

Yeah, unless there's explicit orders from above I don't see them moving (and usually Java people like to live in Java world and ignores everything else)

Google should have started looking at alternatives back them and making another environment first-class on Android as well

(or maybe they can just compile Go to Dalvik and flip the switch, I don't know)

I don't think anyone has used "hip and cool" and "Java" in the same sentence for at least 15 years (2001) and no amount of Android can fix that.

"Damn, that grotesque-looking android startled me and I spilled my cup of Java all over my hip, fortunately it was cool so I didn't get burnt".

This reminds me of that contest where people had to get the phrase "I smoke crack rocks" into a published academic paper, and the winner was something like "we burnt iodine (I) solution to observe its corrosive effect on stone and witnessed I smoke crack rocks".

Java devs talking to me about Groovy always made me chuckle

Groovy has to be one of the most cringe-worthy names in the history of programming languages.

Kotlin? :) --> https://kotlinlang.org/

...which uses the Java API and libs... It's a more pleasant option than Java but it's not going to solve the API copyright issues.

Right ? If they keep putting Google under fire for the use of Java, they will only accelerate the process of Google moving away from Java (which is a huge task mind you) and as a result Java will loose a lot of relevance.

Google have indicated a future Android-Chrome merger. Although the public announcements were to the effect of Android simply replacing Chrome, there has been speculation about other outcomes. Perhaps this suit will encourage movement in the other direction, from Android to Chrome.

They did a proof-of-concept Dart runtime (Sky/Flutter).

The bad news was, that everything was reimplemented in Dart, including the widgets, so they had that not-quite-native feel.

I'd say never. That would kind of be like an apple switching to Swift for iOS.

This is even harder for the Android runtime because it's run on a virtual machine with characteristics that don't easily map to another language.

Basically if they switch to any other language all the apps that currently use Java (ie. all of them) will have to practically use their own VM -which would be slow - or reprogram everything in another language - which would be expensive.

Why would maintaining two runtime make dalvik app slower? They're all interpreted anyway.

They were JIT-ed for a while. That's what the "optimizing apps" modal dialog after updates is about.

>They were JIT-ed for a while. That's what the "optimizing apps" modal dialog after updates is about

I think you meant AOT-ed. The language really doesn't matter though, as long as it can be converted to Dalvik bytecode.

Yes, AOT-ed :)

I was talking about the developer supplying their own VM on top of whatever the new runtime is going to be.

However I suppose they could just add an extra one on the side. I wouldn't really consider that switching though.

Actually as a first step the language could be implemented on top of the dalvik vm. It's just that the IR of go would need to change for that target. Something like Truffle for OpenJDK could help by adopting new languages.

That takes care of the language but none of the API's. I suppose that would be the second step.

It sounds like this all would take a lot of time to complete. What would be the point for Google to do all this work?

I don't see Android team itself is going to switch to Go or Javascript for android. Otherwise, I would say Kotlin[0] would be a better alternative to Java.

[0]: https://kotlinlang.org

I'm curious how switching to Kotlin would help since it relies on the Java APIs and libs...

Kotlin is hip and cool.

Since it outputs bytecode, IANAL but it probably does not helps with Java APIs litigation.

Few things comes to my mind:

Kotlin is JVM + Java interoperable language and this is its major if not sole selling point. So it does not help Google in any way regarding Oracle-Google copyright and patent issues.

Any kind of support might come when some developers get down and write lot of code to support that language. Android team is not going to add any support just because someone wanted or voted to support new language on Android platform.

At least people who wanted Go on android have written extensive amount of code to add support and still they are far from done.

Javascript? I hope never.

Reply on news.ycombinator.com