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?
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 doing something special with the Java source code instead of processing the byte code? Are they doing their own javac compiler?
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.
This is the exact opposite of what I got from reading this blog post... Jack is what did the bad stuff you are talking about, Jill was (apparently: I hadn't read much about it before today) a mitigation for that badness (by allowing you to "link" in .class files), and they finally decided to throw all that away and go back to actually (correctly, in my book) supporting the old javac->dx flow (which guarantees that if they are going to support Java 8, and this blog posts claims they are intending to do so, that they do it by supporting the bytecode correctly, as now all source code has to go through this path and the Java ecosystem of code transformers will continue to work as expected).
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.
Scala 2.12 takes advantage of Java 8's new default methods in interfaces, among others, for encoding Scala's features. We finally have a Scala version that isn't so fragile. And because of the limited resources of the core team, they can't maintain different backends.
Java 8 was released in 2014. I cheered for Google when they won Oracle's lawsuit, but when you're forking the ecosystem, you have a responsibility to keep on your promise of keeping up to date and compatible with the upstream. They just pulled a Microsoft and are getting away with it.
Fuck Google for fracturing the Java ecosystem. There, I said it.
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 in Coffee-script. Your comparison is just wrong.
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.
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.
The parts it does add are small and orthogonal. They can be combined to make surprising things, but that's the mark of a good language - it lets people write very complex libraries, but by combining simple features in ways that make sense.
Specifically, call by name is highlighted in the IDE these days (though I agree we would be better off without it), implicit parameters are really important and it's not hard to ensure consistency, for comprehension is the opposite of what that site is saying (dealing with multiple monads is a lot harder without it, and it's not like ignoring monads as Kotlin does makes the problems you need monads for go away), and the rule about operators is incredibly simple (your method name is just your method name, if you want to write a "" operator you call it "" rather than having to remember what the magic name for overloading that is).
Meanwhile your link ignores the many complex features in Kotlin e.g. delegation, platform types. Maybe they were added since it was written - Kotlin seems to add a lot of ad-hoc features very quickly.
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<String>) {
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.
Also in Kotlin you can have extension methods with multiple receivers:
class Dictionary {
val wordList = setOf<String>()
fun String.isWord(word): Boolean =
word in wordList
}
...
val myDictionary = Dictionary()
with (Dictionary) {
println("dog".isWord)
}
(you can skip the "with" when being inside Dictionary)
> ...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.
Or, you know, just define a plain function.
> which allow you to add new methods to any class without needing to modify the original class
No, those aren't methods, because they don't do dynamic dispatch. This is actually a problem in case you have an inheritance hierarchy and you want different behavior for a ChildClass extending a BaseClass.
Speaking of Scala, it's the only one out of the ones mentioned here that can do that based on the compile-time time, by letting you define the same extension for both ChildClass and BaseClass, but with different priorities, such that the compiler can disambiguate.
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.
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.
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.
> Kotlin has generics that are in most circumstances reified enough ;).
They are not more reified than what you can achieve by just putting Class<T> fields in Java objects to represent the runtime type of the generic type parameter. Sure, Java solution is kinda more verbose and ugly, but this is basically what people already said here: Kotlin has some nice syntax sugar.
But you still can't have two different methods differing only with the generic type parameter (e.g. List<String> and List<Integer>). And the code is still not-specialized properly, read "slow".
Real reification will be possible if project Valhalla arrives (maybe Java 10, who knows?)
> Fuck Google for fracturing the Java ecosystem. There, I said it.
Right on the spot, yet as Silicon Valley darling they get a free pass instead of being blamed like Microsoft was.
I still hope Oracle manages to force them to play by rules.
Other JVM vendors like IBM, Atego, Azul, MicroEJ,.... are able to provide their own extensions, while supporting Java properly and not forking the whole language + standard libraries.
Some of them do sell JVMs for embedded devices with soft and real-time constraints much higher than Android, so the whole story about a Java fork being a requirement for Android is such Google marketing for their actions.
> 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.
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 updates and developer experience.
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.
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.
Now that Xamarin is open source, a reasonably stable Java bytecode -> Xamarin-compatible CIL cross-compiler could be pretty useful. It would also solve the problem of varying VM quality between Android versions (especially around the Dalvik to ART transition).
I don't feel the pain of lack of modern Java support that much, because I spend most of the time on NDK, but there the tooling support also leaves a lot to be desired, like partial STL support or the whole story regarding build infrastructure.
Xamarin looks a nice proposal out of this mess and as a JVM/.NET/C++ consultant, with focus on native apps, I have been looking into it as possible alternative.
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?
To avoid doing a Microsoft move on us that now enjoy the pain of writing not so portable Java code across official standar Java™ and Android devices, thus making a fork in the Java ecosystem.
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.
> Google has shifted to an implementation based on OpenJDK.
No they have not, just go look at AOSP source code.
Yes they are using it instead of Harmony nowadays, but they are cherry picking features and APIs, instead of providing 100% compatibility with the language standard.
>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.
It never was, even the adoption of OpenJDK is a marketing gig, as they are actually cherry picking features, as anyone reading the AOSP source code history can validate.
Is this impression incorrect? Are they doing something special with the Java source code instead of processing the byte code? Are they doing their own javac compiler?