Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Future of Java 8 Language Feature Support on Android

android-developers.googleblog.com

Post reply on HN
Print view View original

61–70 of 103 posts

Re: Future of Java 8 Language Feature Support on Android

#61

Post by pjmlp »

izacus wrote: post #59
pjmlp wrote: post #45

Earlier quoted context omitted.

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.

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

Try to use the SupportLibrary in Samsung devices, or better yet, check the code for device specific workarounds.

Re: Future of Java 8 Language Feature Support on Android

#62

Post by ptx »

maaaats wrote: post #30
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?

I don't really care, now that I'm invested in Kotlin.

It still seems like good news. If they had decided to focus their efforts on Jack (compiling Java source code directly to Dalvik bytecode) the parts of the toolchain that work with Java bytecode (such as the output of the Kotlin compiler) would have been de-prioritized and might not have been as well supported.

Re: Future of Java 8 Language Feature Support on Android

#63

Post by agentjj »

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.

>How will they do that exactly?

Presumably they could have the dx tool in the current toolchain support Java 8 bytecode .class files as input (just as the Jill linker in Jack toolchain allows).

>I thought the whole rationale for Jack was it was a clean break from Sun / Oracle Java and entirely open source.

In the current toolchain you do something like the following: java sources -> javac -> .class files -> dx tool -> dex file -> ...

(We already have an open javac with OpenJDK by the way, and dx is part of AOSP, so "entirely open source" was essentially solved).

Part of the idea behind Jack was that by creating a new compiler toolchain specifically for Android you could have a faster build by jettisoning the unnecessary .class intermediates and going straight to dex from the sources (or rather, as it turns out, a pre-dex that goes into a new intermediate .jack file with other metadata).

Re: Future of Java 8 Language Feature Support on Android

#64

Post by proyb2 »

izacus wrote: post #37
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).

Now you ask, SCADE partners with PerfectlySoft is now release SCADE for beta testing, you can run Swift coding on iOS and Android (Swift or C to JNI support is in their roadmap).

http://scade.io or chat slack channel perfect.ly to chat with the team.

Re: Future of Java 8 Language Feature Support on Android

#65

Post by dep_b »

bad_user wrote: post #25
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.

Kotlin is just a Java++, akin to what CoffeeScript is to JS, a Java with a different syntax. Scala is not just a Java with a different syntax. Because of how traits work and because of how they were encoded in Java's class format, in older Scala versions even adding a method with a default implementation breaks binary compatibility, which is why the history of Scala has been so fraught with compatibility breakage. Sc…

> Kotlin is just a Java++, akin to what CoffeeScript is to JS, a Java with a different syntax.

Kotlin is a smaller language than Java (just based on my feeling actually) yet more safe and in many regards flexible. Kotlin is more similar to Swift, where Swift is aimed at Cocoa and Kotlin at the JVM.

The only thing it really has in common is that it uses the JVM. But F# is not similar to C# just because it has .Net compatibility. Especially if you try to write C# in F# instead of F# according to the gospel.

Just as I've seen tons of code by Objective-C devs that's just the old code translated to the new code a lot of Java devs probably won't really get Kotlin and will write the same code as they would do in Java.

Re: Future of Java 8 Language Feature Support on Android

#66

Post by scarface74 »

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.

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.

Re: Future of Java 8 Language Feature Support on Android

#67

Post by dep_b »

pkolaczk wrote: post #52
cel1ne wrote: post #48

Earlier quoted context omitted.

Kotlin is not CoffeeScript for Java. Kotlin is Java done much better. Null as syntax, extensions with receivers, reified typing, type-safe builders, first-class lambdas, sealed classes, co-routines and so much more... Kotlin is my language of choice for just about everything at the moment. I have done 15+ years of programming in Java (Desktop, Server, Android), JavaScript (ES5, ES6+), Kotlin and a little programming…

Kotlin doesn't really have true reified generics (any more than e.g. Scala has), Java 8 has first class lambdas, extension methods and @Nullable now. Kotlin is just Java 8 with cleaner syntax.

The @Nullable syntax is akin to putting a band-aid on a rotting leg. You cannot fix Java without breaking compatibility with older code. They only way to see it is not to look at the problem from the inside out when you have been surrounded with Java for perhaps decades in your career.

In my code null-pointer exceptions or similar accidents (force unwrapping something that simply doesn't exist) never happens anymore. Not in my libraries and not in my program code. A whole class of bugs just gone. Simply because I have to prove that something exists before I use it at compile time already.

It's like having security that starts with everything turned OFF for a default user instead of ON.

Re: Future of Java 8 Language Feature Support on Android

#68

Post by signal11 »

ptx wrote: post #36
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.

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 withou…

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.

Re: Future of Java 8 Language Feature Support on Android

#69

Post by exabrial »

saurik wrote: post #41
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

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

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.

Re: Future of Java 8 Language Feature Support on Android

#70

Post by agildehaus »

izacus wrote: post #31
sjellis wrote: post #27

Earlier quoted context omitted.

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

I'm unable to convince my employer to use Kotlin. Having Google put their weight behind it would tremendously help that situation.
Post reply on HN