Hacker News Reader

Comment by cpprototypes | Hacker News Reader

I like the changes in Java 8, but I'm concerned about Java fragmentation between Oracle/OpenJDK and Android. It seems Android is stuck on Java 1.6 (since Dalvik is not "true Java" and is more like a VM that happens to implement a language very similar to Java 1.6). There's now a huge gap between 1.6 and 1.8. It's not just syntax like lambda and default methods. It's also the supporting API changes in collections (streams) and others. Dalvik was based on Apache Harmony which is a dead project and will never get the Java 8 API changes implemented. Does anyone know if Google is going to do something about Java 8 and Android?

View on HN

Dalvik is being slowly replaced by ART (Android RunTime). Also, you can pretty easily hack Java 7 or even Java 8 into Android to use lambdas. Official, default support is coming soon.

http://tools.android.com/tech-docs/new-build-system/user-gui...

http://zserge.com/blog/android-lambda.html

Except those lambdas are not as efficient as the standard compliants VMs, as they make use of invokedynamic to generate better code, even inline calls for small lambdas.

Which might be fixable with ART as it's an on-device ahead-of-time compiler (I think it optimizes too? can't find references...). I have no idea if it actually does work for this in practice or not, though.

True, but it won't help users with KitKat and lower devices. We all know that they won't see any vendor updates.

Well sure. But people don't update their Java installs either, neither do all businesses. They're likely not going to be able to take advantage of v8 stuff. And can dumbphones on a Java platform (Symbian? Nokia? Others?) run the new Java flashiness? Every platform has problems like this.

Are you sure about that? I've looked at the way invokedynamic generates lambdas, and it's just generating anonymous classes at runtime using ASM. Inlining is from the JIT and applies to anonymous classes as well. I'm pretty sure you can get the exact same results without invokedynamic, you just have a lot more .class files to distribute.

I am basing my comment on the Java One talk about Java 8 lambdas implementation on the Oracle JVM.

I assume other certified JVMs would follow similar design approaches.

I think you got it right. According to Grzegorz Kossakowski's comment (which is more accurate than the misleading article) : http://www.takipiblog.com/2014/01/16/compiling-lambda-expres... , Java 8's lambda's aren't particularly efficient. They do create an anonymous class instance at runtime, as you say. Scala closures are implemented in a similar way, without invokedynamic, and as he says, and currently there is no performance win from invokedynamic's use in Java 8 vs the Scala impl. But it does hold promise of future optimizations, as he says:

"However, the key thing about invokedynamic is that it's essentially a JVM-level macro that defers lambda translation strategy to LambdaMetaFactory which is a library class. If Java 9 or 10 gets more direct (and performant) support for lambdas that won't require classes and object allocations then it can swap implementation of LambdaMetaFactory and all _existing_ code written for Java 8 will get performance boost. That is the brilliance of using invokedynamic in context of translating lambdas. We'll have to wait for future versions of Java to experience those benefits, though."

I don't think that person understands how it works at all.

He knows what he is talking about & his description matches the explanation by Brian Goetz.

So unless I'm missing something, please be specific.

Well, for one, Lambdas are desugared into methods, not anonymous classes. Early on they used anonymous classes because it was convenient but that wasn't the final translation strategy.

http://cr.openjdk.java.net/~briangoetz/lambda/lambda-transla...

Yes, and these methods create an anonymous class at runtime. What's so hard to understand about this?

It was a misunderstanding on my part about where they were claiming the anonymous class was generated. Early versions of Lambda were nothing more than sugar on top of anonymous inner classes and the claim above sounded very similar to that. However, I see that inside the LambdaMetaFactory anonymous classes are generated based on the call site. Probably the biggest difference is that Java 8 can avoid an object allocation when the lambda doesn't capture. Not sure if Scala supports this but I'm sure that it could do it.

My impression from the openjdk code is that each lambda generates:

1. A method in its parent class. 2. An invokedynamic instruction at the call site.

The invokedynamic instruction calls LambdaMetafactory, which compiles an anonymous class at runtime that calls method #1. So the only benefit of using invokedynamic is fewer class files, by deferring generating them until runtime.

Non-capturing lambdas also don't instantiate a new object at each call site. But this is also doable without invokedynamic.

Since I cannot edit my reply.

Have you checked this talk at Java ONE?

http://parleys.com/play/5251c164e4b0a43ac1212459/about

Some older slides also available

http://www.slideshare.net/jaxlondon2012/lambda-a-peek-under-...

But it allows people to move forward using the syntax itself.

The implementation can be optimised at any point.

>> Official, default support is coming soon.

Default support of ART or Java 8?

If Java 8, how do you know this? Citation needed ;)

Java 8.

Arguing whether Java 8 will be completely supported or not ignores the nature of the Android API. Android doesn't even support 100% of Java 6 because it is not a desktop JDK and does not intend to replicate everything.

However, the Android team has actively been adding default support of Java 7 features piece by piece in recent months. They intend to handle Java 8 in the same manner. It's not clear which features will be supported in what version of Android, but lambdas are clearly a priority and can already be used today by early adopters using retrolambda.

http://stackoverflow.com/a/22303654/1412973

There is a good reason that Sun didn't want this to happen and tried to stop it in court — successful against Microsoft, failed against Google. If I remember right, most everyone on here was rooting for Google to win and continue to fragment the language.

The question is what Oracle would lose by licensing real Java to Google at reasonable conditions. Mobile non-Android Java is deader than dead.

> Mobile non-Android Java is deader than dead.

Lots of embedded devices make use of J2ME, e.g. cars, manufacturing, electricity monitoring...

How many of those will get Java 8 updates?

The billionaires at WhatsApp beg to differ. They got very very rich from "mobile non-Android Java".

Isn't their stack based on Erlang or am I missing something ?

You're missing the client side. It runs on J2ME-powered feature phones.

And on Android (and probably iPhones). Which version was first, J2ME or smartphone one?

Oracle was offering licensing for "real Java" at around $1 per device. This was too high for Google that wanted to make it entirely free. Kind of silly, since Android hardware manufacturers pay much more than that to Microsoft in patent licenses.

It's unlikely that the patent licensing situation would have been different with Java ME. It is entirely likely that it would not have been completely open source due to Sun (and ultimately Oracle) restrictions on Java ME.

I have since repent myself.

Google did indeed managed to pull a Microsoft and now we have a forked Java implementation getting steady behind the standard Java implementations.

Even J2ME is more compatible with its big brother than Android.

KitKat has now partial support for Java 7, with libraries still missing some pieces. Dalvik and ART still don't support invokedynamic bytecode.

And since almost no one has KitKat, one cannot use try-with-resources anyway.

I wrote a lot of J2ME stuff a few years ago and you're spot on. I spent two weeks doing Java 8 bits with NetBeans which was really nice and spent the last two evenings writing my first Android app and what a complete mess it is. Plus the Android tooling is horrible to get working reliably - most problems being solved by "restart eclipse".

Late edit: perhaps Oracle should make a phone ;)

I also did some J2ME stuff back in 2003, most with Sharp and Nokia devices.

I read somewhere that some in the Android team are C converts doing their first Java gig.

Have you seen how broken are the generated Renderscript bindings? They don't have anything to do with Java conventions and feel completely out of place.

Haven't looked at render script yet. Still scratching head on the layout engine stuff and View infrastructure. It's fugly. I usually write C#+WPF and C++/Qt and HTML/Java EE and all of those are massively nicer to deal with.

If you are two days in and still getting around how Views and layout works I wouldn't call it a mess yet. You are still pretty early into it. Its not messy its just new to you.

From my experience once you get past the initial hump of learning their basic APIs and conventions its a very easy to work with platform. Maybe I am biased because I spend a lot of time with it. I also really like the tooling. How is it acting unstable for you?

> Late edit: perhaps Oracle should make a phone ;)

They did an open spec tablet with a raspberry pi tough.

https://wiki.openjdk.java.net/display/OpenJFX/DukePad

Chuck a GSM module in it and done :)

> Plus the Android tooling is horrible to get working reliably - most problems being solved by "restart eclipse"

Try Intellij IDEA / Android Studio. I find them quite reliable.

Intellij IDEA, yes.

Android Studio seems to still have performance issues with Gradle on Windows, specially when indexing stuff.

Agreed. I prefer IntelliJ IDEA Community Edition to Android Studio because I like using the same IDE for Android and Java development.

> "restart eclipse"

Eclipse

/shudder

After this week, yep!

> Even J2ME is more compatible with its big brother than Android.

Are you serious?

J2ME is even more crippled than Android's Java (no reflection, no Swing, no AWT and stuck in Java 1.4).

J2ME has been dead for more than half a decade and we have Android to thank for that. Good riddance.

I'm not sure where you get your information about this, but J2ME 8 was released alongside Java 8:

http://www.oracle.com/technetwork/java/embedded/overview/jav...

No invokedynamic though :-) https://jcp.org/en/jsr/detail?id=360

Also missing:

    Reflection
    Serialization
    Lambda expressions (JSR 335)
    JNI and application native code
    User-defined class loaders
    Full annotations support (Runtime annotations)
    Thread groups and demon threads
    Full Math APIs (with BigDecimals)
    Concurrency utilities
    Full security APIs
    Full collection APIs (Sorted collection classes)

Source: http://docs.oracle.com/javame/config/cldc/opt-pkgs/api/cldc/...

J2ME has been updated to Java 8 and outside the mobile world is used a lot in embedded industrial deployments.

I supported Google because the ends don't justify means. People should have the right to re-implement APIs, even if we sometimes wished they didn't.

Well put. Just because it wasn't a good idea doesn't mean it should be illegal.

Forked != out of date. Android code is still Java code. you just compile to Dalvik bytecode instead of jvm bytecode.

If you think that's wrong, fine but that lawsuit had nothing to do with bytecode.

Hmm, what you write makes no sense.... even if Google would use Oracle Java, we'd still be stuck with devices running Java 1.6 JVMs.

Having a different implementation doesn't change the limitations imposed by out of date VM running on a device.

Why would they run 1.6 JVMs? Why wouldn't they run the latest?

Android already supports most of Java 7 http://tools.android.com/tech-docs/new-build-system/user-gui...

I'm not aware of any plans to support Java 8 yet, but I haven't been looking.

They support Java 7 syntax, however they do not have the API improvements in Java 7. For example, Java 7 introduced a much improved File IO API in the java.nio.file package. It has very useful classes like Files (http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files...)

Android does not have any of this (http://developer.android.com/reference/packages.html) because the Apache Harmony project died before it could implement Java 7 API changes.

This is a much bigger issue for Java 8. Just supporting only Java 8 syntax changes greatly reduces the benefits of the new lambda and default methods. Much of the power of the changes, especially lambda, require the changes to the collections API.

Guava works on it though, thank goodness!

No, Android does not have any of this because Apache Harmony was killed by the Java 7 API changes. Namely, the documentation was no longer open, and Oracle withheld the TCK, effectively killing Harmony by making it uncertifiable as a Java implementation.

Harmony didn't die per se - It was killed by Oracle. Google's rationale for engineering a Java-ish VM with Java APIs was only legal up until Java 6.

If you target only KitKat and don't mind missing some of the Java 7 new APIs.

There's always been some fragmentation between Dalvik and "real" Java. A lot of libraries don't work out of the box on Android.

Not to mention debacle it creates on your system. Android requires/plays-well with JDK 6 and you probably want to be running the latest version of Java for security purposes. Maintaining multiple JDKs have been nothing but troubling for me.

Uhm... Android tools work just fine with the newsest stable JDK 7.

I hear not all libraries are supported. developer.android.com and almost all tutorials/courses recommend using JDK 6.

Especially since Google hasn't updated its Java language much lately. I think the solution for Google is to deprecate Java and start using Go. That would solve more than one problem for them.

Back when I was initially impressed by Go before the 1.0 release, I created a ticket for Go on Android, which is still open.

I doubt it will ever happen.

There are a bunch of rumors that Google will announce expanded GoLang support on Android at IO. What that means I'm not sure and I can't find the link for it now. It was a somewhat credible source but not one I'd bet the farm on or anything. I suspect if anything is announced it would be GoLang ndk support but we can dream and hope for more. A python to Davlik compiler would be a very interesting move also.

> A python to Davlik compiler would be a very interesting move also.

Dalvik is dead. It has been already fully replaced on the latest AOSP code drops. Plus SL4A was left to rotten.

As for Go, lets see. My ticket is now two years old.

> Especially since Google hasn't updated its Java language much lately

Yes it has. They recently added Java 7 language support.

Reply on news.ycombinator.com