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

51–60 of 103 posts

Re: Future of Java 8 Language Feature Support on Android

#51

Post by _pmf_ »

pjmlp wrote: post #29
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…

Google has no interest in providing the right support for Java developers it seems. Lack of Java 8 bytecode now, then lack of Java 9 modules tomorrow, and eventually lack of Java 10 value types and improved generics, arrays and JNI replacement. And of course, lack of many of the SE APIs in any case. The fun of writing portable libraries between Java and Android Java is only getting better.

I think their legal shenanigans regarding usage of Java technology plays a major role here: they simply do not own Java technology. It was a horrible mistake to use it without Sun's/Oracle's approval and as soon as the first lawsuit ends in favor of Oracle, they will be milked to an extent that has not yet been seen.

Re: Future of Java 8 Language Feature Support on Android

#52

Post by pkolaczk »

cel1ne wrote: post #48
bad_user wrote: post #25

Earlier quoted context omitted.

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

Re: Future of Java 8 Language Feature Support on Android

#53

Post by pjmlp »

izacus wrote: post #50
pjmlp wrote: post #46

Earlier quoted context omitted.

Swift is officially an Apple language. While Kotlin is nowhere to be seen on Android SDK and Google is officially silent on its use. This matters a lot to customers IT departments, writing the set of delivery languages on their Requests For Proposal to consulting companies.

Ruby, Python, JavaScript, Java and others also aren't "official Google", "Apple", "Microsoft" languages and they still run the whole web. It really question the brokenness of a company processes that refuses to use good tooling just because a corpo didn't tell them to. Kotlin is full interoperable with Java APIs and libraries and at this point there's really very few cases where it's not a significantly better choice…

It is not the question of telling to, it is the question of accepting to sign the contract at all, or pay at the end.

Re: Future of Java 8 Language Feature Support on Android

#54

Post by pjmlp »

_pmf_ wrote: post #51
pjmlp wrote: post #29

Earlier quoted context omitted.

Google has no interest in providing the right support for Java developers it seems. Lack of Java 8 bytecode now, then lack of Java 9 modules tomorrow, and eventually lack of Java 10 value types and improved generics, arrays and JNI replacement. And of course, lack of many of the SE APIs in any case. The fun of writing portable libraries between Java and Android Java is only getting better.

I think their legal shenanigans regarding usage of Java technology plays a major role here: they simply do not own Java technology. It was a horrible mistake to use it without Sun's/Oracle's approval and as soon as the first lawsuit ends in favor of Oracle, they will be milked to an extent that has not yet been seen.

Every other commercial JDK vendor is able to comply with licenses and still provide language extensions and their own VM stacks. There are quite a few examples to chose from.

Why should Google be a special snowflake that doesn't play by the same rules?

Re: Future of Java 8 Language Feature Support on Android

#55

Post by sangnoir »

pjmlp wrote: post #45
izacus wrote: post #35

Earlier quoted context omitted.

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.

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

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.

Re: Future of Java 8 Language Feature Support on Android

#56

Post by agentjj »

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…

>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

To quote the article: "We've decided to add support for Java 8 language features directly into the current javac and dx set of tools."

The way I'm reading that could (maybe) work, the regular toolchain (javac -> .class files -> dx -> dex file) would get an upgraded dx tool that could take classes with Java 8 bytecode as input. In that case something like Scala (or any compiler that outputs Java 8 bytecode classes) would be just as well supported.

Re: Future of Java 8 Language Feature Support on Android

#57

Post by cel1ne »

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.

Kotlin has generics that are in most circumstances reified enough ;).

Optionals of Java8 and Guava are a terrible idea. @Nullable is just an annotation. Null-safety built in the language is the only way to go.

You could always argue that a language is just cleaner syntax. Kotlin is a cleaner syntax for interacting with JVM-bytecode. Scala is a also cleaner syntax for interacting with JVM-bytecode. JVM-Bytecode is a cleaner syntax for interacting with operating systems.

Re: Future of Java 8 Language Feature Support on Android

#58

Post by ptx »

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.

I'm no expert on Java 8, but it looks like the new feature they call "extension methods" is just the ability to define methods in interfaces and inherit them, essentially like a concrete method in an abstract base class, isn't it?

The "extension methods" in Kotlin (and C#) is a completely different feature: syntactic sugar for static utility methods, which allow you to add new methods to any class without needing to modify the original class. (Or at least make it look that way syntactically.)

So in Kotlin you can do this:

  fun String.toLeetSpeak(): String {
     val charmap = mapOf('e' to '3', 'l' to '1')
     return this.map { charmap[it] ?: it }.joinToString(separator="")
  }

  fun main(args: Array) {
      println("Hello!".toLeetSpeak())
  }
...whereas in Java you would have to change (and have access to) the implementation of one of the classes or interfaces that String inherits from.

Re: Future of Java 8 Language Feature Support on Android

#59

Post by izacus »

pjmlp wrote: post #45
izacus wrote: post #35

Earlier quoted context omitted.

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.

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.

Re: Future of Java 8 Language Feature Support on Android

#60

Post by pjmlp »

sangnoir wrote: post #55
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 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 M…

There was this thing called LWUIT and Sony supported Nokia extensions.

> no one who ported J2ME apps would say what you did with a straight face. > 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.

How is Android any different? Should I start listing differences among devices here?

Post reply on HN