[pianoben]

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!

[lstamour]

Just turn them off or use Android Studio, which I believe still has sane defaults. Help file on this: https://www.jetbrains.com/help/idea/2016.3/disabling-and-ena...

Also, if looking for APIs, and willing to risk having to tweak code later, there are a few "polyfills". For example: https://www.google.ca/amp/s/barta.me/enable-java-8-features-...

[exabrial]

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

[saurik]

AFAIK they did this to 1) improve runtime link/startup times (so, a similar reason why many other mobile devices have their own class file formats; for more information, read my introduction to the subject, linked below), and 2) to make sure they were not violating various bytecode-related patents from Sun that relied upon a stack machine.

http://www.cydiasubstrate.com/id/727f62ed-69d3-4956-86b2-bc0...

[exabrial]

1) I don't believe. I'm not talking sun's JVM, just the byte code. We have jvms with super fast boot times already, just not openjdk.

2) interesting. I wasn't aware of these. It would have been useful to get sun involved in the project, but they didn't.

[saurik]

Did you read my article? (Because your comment doesn't seem to bring up any actual rebuttal of the point, which makes me think you didn't, which makes me hesitant to waste more of my time explaining it, particularly as it might make it seem OK to just toss aside arguments with "I don't believe" as the other person will then just do more work in the conversation.) The problem with bytecode is that it has complex linking and relocation issues. DEX was specifically designed to convert trivially to ODEX, and which hardcodes vtable and field offsets to make interpretation trivial and fast, while also letting the code be memory mapped between processes. FWIW, current versions of Android have expanded the optimization step all the way up to something more like a compiler, but it took them many many years to get to that point. Since you are speaking with someone who is extremely familiar with VM design, as well as the history of the Android project and its unique limitations, would you mind being more specific with what you feel is inaccurate? (I am totally willing to believe I missed something, as I spend way way more of my time on iOS internals, and I am "rusty" with VMs--though not so much that the students I teach to about them notice horribly ;P--but it just doesn't seem like that so far.)

[hota_mazi]

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.

[ptx]

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

[signal11]

Hey, a fellow K800i owner! I loved that phone, used to run Gmail on it (J2ME app). For its time it also had a pretty good camera. As far as I remember it didn't have a headphone jack though, just some weird proprietary headphones.

[bjbX]

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.

[izacus]

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.

[pjmlp]

I guess you never had the fun to port Android code among OEMs, using OEM specific SDKs for specific features like real time audio, or work around firmware bugs specially on Samsung devices.

Android fragmentation is no different than J2ME used to be.

[sangnoir]

> Android fragmentation is no different than J2ME used to be

That has to be hyperbole: no one who ported J2ME apps would say what you did with a straight face. Even a run-of-the-mill app with no esoteric features would need to be ported because Nokia's methods had different signatures to SonyEricsson's for text fucking rendering, because why not. The entirety of J2ME an "OEM specific SDK" This is before considering MIDP, CLDC versions and goddamn model-specific processor and memory differences. "Android fragmentation is no different than J2ME used to be" my ass.

[izacus]

> Android fragmentation is no different than J2ME used to be.

This is a huge overstatement. J2ME was fragmented in things like basic UI with no tooling to handle it. In Android you really need to dig into hardware-specific funcionality (or really really mess up UI design) to be severely affected by the fragmentation.

[scarface74]

Dalvik has nothing to do with Android's popularity. Android's popularity is caused by.

1. Price - you can buy an unlocked Android device for $50.

2. It is free to manufacturers

3. No alternative for phone manufacturers at first. By the time Windows Phone git good enough, it was too late.

[pjmlp]

No, Android became popular due to the Google loving hipsters that believed in FOSS and AOSP, and OEMs that just love getting an OS for free with almost no strings attached.

Every other commercial Java vendor in this planet doesn't have any issue using standard Java tools, compiling with Java licenses and deliver JVMs able to run in embedded devices with soft and hard real time constraints.

Google for all their might is a special snowflake not able to do what the rest of the Java world is capable of.

[geodel]

This sounds strange. Seems Next you will start claiming that Oracle DB is popular because Oracle loving hipsters like paying for heavy licensing fee and support and not because it is high performance DB for critical enterprise requirements.

[izacus]

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.

[DiabloD3]

You can turn that on and off in the settings in IntelliJ already, and it only enables that suggestion if you're using a Java 8 JDK.

If it is suggesting it on a correctly configured Android project, I suspect you found a bug.