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

71–80 of 103 posts

Re: Future of Java 8 Language Feature Support on Android

#71

Post by lmm »

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…

If Kotlin wasn't just CoffeScript for Java but a whole new language then there would be no reason to use it instead of Scala. There's an excluded middle here: either it's a very-close-to-Java language (in which case probably not worth the cost of using) or it's a language that's significantly different from Java (in which case it has no interop/familiarity advantage over Scala and the two languages have to be compared on their merits - and I'd say Kotlin comes off pretty poorly in that).

> It's 100% compatible to Java so of course it's not a completely different language. Haskell is a different language. I like Haskell, but I'm glad that I don't have to convert all my old java code to it.

> I can open old java-projects and use Kotlin on a file-by-file basis without any problems.

Sure. I do exactly that in Scala too.

Re: Future of Java 8 Language Feature Support on Android

#72

Post by geodel »

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

Exactly right. Only in La La Land Google would ignore their own languages like Dart and Go and go on to officially support some random JVM language.

Re: Future of Java 8 Language Feature Support on Android

#74

Post by geodel »

pjmlp wrote: post #54
_pmf_ wrote: post #51

Earlier quoted context omitted.

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?

Well that special snowflake is sued and they are having their day in court. Oracle has extinguished many rivals in court and maybe they will do it again.

Re: Future of Java 8 Language Feature Support on Android

#75

Post by geodel »

pjmlp wrote: post #24
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.

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…

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.

Re: Future of Java 8 Language Feature Support on Android

#76

Post by oblio »

pjmlp wrote: post #44
izacus wrote: post #31

Earlier quoted context omitted.

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

Our customers do, if it isn't a vendor supported language on platform X, usually their IT doesn't allow it on their list of languages for project delivery.

Are they the kind of folks that demand that you use .NET or C++ on Windows? I had a colleague like that. I had to explain to him that people are actually using Java or Python in production, on Windows.

Re: Future of Java 8 Language Feature Support on Android

#78

Post by dkarl »

ptx wrote: post #42
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…

My impression from the post was that they were going back to the old (standard) way of letting the standard javac compile Java to bytecode and then letting dx convert it to Dalvik bytecode, but now with the addition of Java 8 bytecode support in dx. Their stated reason is precisely what you bring up: compatibility with tools that work with the bytecode, like the Scala compiler. Is this impression incorrect? Are they…

At second glance it looks like you're right. When they say "add support for Java 8 language features directly into the current javac and dx set of tools" I read that as directly adding Java 8 language support into the javac already in the toolchain, but the comment bitmapbrother quoted links to a tool that operates on Java 8 bytecode[1]. I guess they are adding Java 8 bytecode translation as a part of dx or as a build step between javac and dx.

If they aim to translate all valid Java 8 bytecode (and not just classes emitted by javac) then the situation is at least as good as we would have got with Jill.

[1] "Command-line tool to desugar Java 8 constructs that dx doesn't know what to do with, in particular lambdas and method references." https://github.com/bazelbuild/bazel/blob/master/src/tools/an...

Re: Future of Java 8 Language Feature Support on Android

#79

Post by lmm »

cel1ne wrote: post #57
pkolaczk wrote: post #52

Earlier quoted context omitted.

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

Optional is a concept that you need even in a null-safe language (e.g. Haskell has Maybe). With language-level nullability you can sort-of emulate a pseudo-Optional type, but why would you want to? It's inherently second-class because it can't ever be properly compositional (Option[A] is always a different type from A and can be understood without knowing anything about A, whereas A? might or might not be a different type from A, you can't understand what it does without knowing the details of what A is).

Once you start interacting with JVM bytecode Kotlin ceases to have null-safety. @Nullable is just an annotation but at least you can write it down, unlike Kotlin's "platform types". Conversely if you're not interacting with non-Scala bytecode then Scala is null-safe in practice if not in theory, because the Scala ecosystem doesn't use null and has tools to enforce this.

Re: Future of Java 8 Language Feature Support on Android

#80

Post by Larrikin »

lmm wrote: post #71
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…

If Kotlin wasn't just CoffeScript for Java but a whole new language then there would be no reason to use it instead of Scala. There's an excluded middle here: either it's a very-close-to-Java language (in which case probably not worth the cost of using) or it's a language that's significantly different from Java (in which case it has no interop/familiarity advantage over Scala and the two languages have to be compare…

One of the arguments against Scala is that its large and simply too feature rich. https://agilewombat.com/2016/02/01/scala-vs-kotlin/
Post reply on HN