Future of Java 8 Language Feature Support on Android • Hacker News Board

Re: Future of Java 8 Language Feature Support on Android

#31

Post by izacus » Wed, Mar 15, 2017, 8:03 AM UTC

sjellis wrote: post #27

makeramen wrote: post #12

Earlier quoted context omitted.

Kotlin is committed to Android support though, and the community is coming to rally behind it much more than Scala.

I actually clicked on the link with the faint hope that there would be something in the announcement about Kotlin. Google support for Kotlin, or some initiative to get a grip on security updates are the only announcements that I really want to see about Android at this point: I use an Android phone, but there's no end-user things that I feel that it lacks right now. IMO, the significant weaknesses of the platform are…

Why would Google have to announce anything about Kotlin? Do you wait For Apple to announce something about Python before using it on your mac?

(We're running Kotlin in production for a long while now and at this point I think starting development of an app in Java is rather silly considering how stable and nice Kotlin is.)

Re: Future of Java 8 Language Feature Support on Android

#32

Post by izacus » Wed, Mar 15, 2017, 8:21 AM UTC

future1979 wrote: post #20

Tldr for newbie? What is jack all about? I thought android had moved away from dalvik to art in lollipop. In nougot, I thought android was going to use openjdk in some parts. Can anyone knowledgeable shed light?

ART and Dalvik are VMs that run on your phone. They're a different implementation of a JVM you know from desktop systems and run a special (non-desktop Java compatible) DEX bytecode format.

This is about the toolchain. The standard Android toolchain uses standard OpenJDK/Oracle JDK Java compiler to compile your app code into standard java class files and then uses dex tool to translate that bytecode into Dalvik/ART DEX bytecode.

Jack toolchain was all about replacing this javac -> dex step with a single fast compiler which would also support more Java 8 features and translate them into DEX format while taking into account feature limitations of ART/Dalvik runtime. The downside was that it didn't support bytecode manipulation tools (tools that work on Java class files before they're translated into dex format) and annotation code generators. Since a lot of good Android libraries rely on annotation generation that was a pretty huge deal breaker.

This news is about Google abandoning the Jack project and retrofitting the improvements and partial Java 8 feature support into current toolchain.

Re: Future of Java 8 Language Feature Support on Android

#33

Post by izacus » Wed, Mar 15, 2017, 8:21 AM UTC

akent wrote: post #14

When they say "into the current javac and dx set of tools" what are they meaning there? How will they do that exactly? I thought the whole rationale for Jack was it was a clean break from Sun / Oracle Java and entirely open source.

So is OpenJDK and DEX tool used right now.

Re: Future of Java 8 Language Feature Support on Android

#34

Post by izacus » Wed, Mar 15, 2017, 8:24 AM UTC

pianoben wrote: post #5

This looks to be "language features" only - so, lambdas, but no Java 8 APIs. Optionals, streams, etc are not included. ...I hope they fix IntelliJ's default suggestions, which try to turn all of your loops into `.stream()` calls!

Well, you can hardly add those features onto devices that don't have them in their standard library. Even now all the features that require modification of the runtime are restricted to the VMs actually supporting them (e.g. try-with-resources since Android 4.4, most other new Java 8 features since Android 6.0 I think).

(Yes, it would be nice if new Android versions would expand the standard library).

In the end I don't see that as a huge restriction - instead of java.time there's ThreetenABP, instead of streams there's better RxJava, etc. With added bonus that you're not limited to whatever libraries device ships with, but you bring your own always up to date ones.

Also, right now, any new project should pretty much be started in Kotlin which does everything that Java 8 does better and is bytecode compatible with Android VMs.

Re: Future of Java 8 Language Feature Support on Android

#35

Post by izacus » Wed, Mar 15, 2017, 8:25 AM UTC

bjbX wrote: post #21

hota_mazi wrote: post #19

Earlier quoted context omitted.

It would have been a disaster. The JVM of 2007 would have run crazy slow on the devices from back then. Dalvik is the main reason why Android became so popular.

Every feature phone on the planet used to run Java ME without any problem. Dalvik may have had some optimisations, but to claim Java would have run "crazy slow" is unlikely to be the reason Google chose the implement their own VM.

JavaME was a total disaster of incompatibilities, lack of any useful API and broken platform support.

The fact that you can use a lot of standard Java libs with Android was and is a huge boon that makes development significantly easier than the hell that was JavaMe.

Re: Future of Java 8 Language Feature Support on Android

#36

Post by ptx » Wed, Mar 15, 2017, 8:25 AM UTC

hota_mazi wrote: post #19

exabrial wrote: post #11

Earlier quoted context omitted.

I feel like Google really got bit by "not invented here" syndrome on the original Android vm :/ using normal JVM bytecodes might have been a good idea

It would have been a disaster. The JVM of 2007 would have run crazy slow on the devices from back then. Dalvik is the main reason why Android became so popular.

Back in 2008 when Android phones were first released, there was a blog post[1] about Dalvik's (lack of) performance and I decided to try it on my Sony Ericsson K800i[2], which was released in 2006 and ran Java ME apps (and miraculously even had an "app store" even though Apple wouldn't invent it until 2008).

The microbenchmark in the blog post ran in 922 milliseconds on the Google G1 (a.k.a. HTC Dream), or 520 without the assignment in the loop. On my K800i the corresponding numbers were 190–220 ms and 135–165 ms – although I had to scale the size of the buffer down from 1228800 to 1100000 elements due to lack of memory, but scaling the results up by that factor the K800i was still 3–4 times as fast as the G1.

Hardware-wise the G1 should have been much faster. It had an ARM11 at 528 MHz and the K800i had (I think) an ARM9 at somewhere around or below 200 MHz.

[1] http://web.archive.org/web/20091123074004/http://occipital.c...

[2] https://en.wikipedia.org/wiki/Sony_Ericsson_K800i

Re: Future of Java 8 Language Feature Support on Android

#37

Post by izacus » Wed, Mar 15, 2017, 8:26 AM UTC

Cyph0n wrote: post #4

Sounds like good news to me, but I'm not sure why this is not getting more attention. Isn't Java 8 support a huge deal for Android, or am I missing something?

At this point I think any serious shop should be transitioning to Kotlin (just like iOS shops are transitioning to Swift).

Re: Future of Java 8 Language Feature Support on Android

#38

Post by izacus » Wed, Mar 15, 2017, 8:26 AM UTC

lern_too_spel wrote: post #15

relics443 wrote: post #2

Well that was unexpected. I'm assuming they'll translate bytecode for older API versions? Or will Java 8 only be available for newer API versions?

Are you expecting anybody from the Android team to explain themselves? They've been answering every question about Java 8 with "no comment" for years. They didn't even discuss Jack/Jill's relation to Java 8 support when the tooling was announced, and external developers had to figure out Android's plans on their own from what they could decipher from the architecture.

Huh, Android team has been explaning themselves around Java 8 issues a lot (look at I/O talks, linked redding thread in another comment here, etc.)

Re: Future of Java 8 Language Feature Support on Android

#39

Post by izacus » Wed, Mar 15, 2017, 8:28 AM UTC

relics443 wrote: post #2

Well that was unexpected. I'm assuming they'll translate bytecode for older API versions? Or will Java 8 only be available for newer API versions?

Yeah, it does a similar thing like RetroLambda - things like lambdas are polyfilled and replaced on bytecode level. Some features require newer VMs and I'm afraid standard library won't be expanded with new APIs.

See https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o...

Re: Future of Java 8 Language Feature Support on Android

#40

Post by saurik » Wed, Mar 15, 2017, 8:35 AM UTC

dkarl wrote: post #10

The possibility of running Scala >=2.12 (or any other language that is committed to Java 8[1]) on Android seems even more remote now. Jack+Jill at least promised a way of running Java 8 bytecode on Android[2]. What now? Is Java source code going to be the only common currency between the Java 8 and Android ecosystems? [1] https://www.scala-lang.org/download/#Software_Requirements [2] http://stackoverflow.com/question…

This is the exact opposite of what I got from reading this blog post... Jack is what did the bad stuff you are talking about, Jill was (apparently: I hadn't read much about it before today) a mitigation for that badness (by allowing you to "link" in .class files), and they finally decided to throw all that away and go back to actually (correctly, in my book) supporting the old javac->dx flow (which guarantees that if they are going to support Java 8, and this blog posts claims they are intending to do so, that they do it by supporting the bytecode correctly, as now all source code has to go through this path and the Java ecosystem of code transformers will continue to work as expected).