I'm not sure if Dart is the answer, but Google definitely has to do something about it's "language problem" on Android. Especially with Apple introducing a modern language in Swift. It's a shame that all of the great JVM languages don't easily work on Android or they wouldn't have the problem.
Though I understand their reasoning to a degree, it does seem perverse that they adopted the most pedestrian bit of java -- the language -- while jettisoning the crown jewel -- the JVM.
It hasn't been trivial to get other JVM languages working on Android, and ironically that list now includes Java 8.
You can't make an open source platform around a core that requires a commercial license. Had Google done as you suggest, there would be no AOSP, which is fairly strategically central to Android.
Tactical choices are constrained by strategic goals.
> I was talking about third-party OS builders, which could anyway pay for licenses as they always did.
Or they could build their own OS's from scratch, as they always have also done, sure; but an important part of Google's strategy, though, was to make the core of Android open source, which they couldn't do if something as fundamental as the basic runtime required a paid license from a third party. And AOSP is -- empirically -- not useless to third party builders without the separately-licensed Google services.
> End users have no use for open source, besides free beer.
Just-for-me modifications are a real thing, if maybe not all that common, so I wouldn't say "no use".
I think it makes very much sense for Google to start pushing Kotlin. It runs on JVMs. It is compiled. It's a simple language to migrate to for Java developers, but provides more convenience than Java 8. It does not have the impedance mismatch with Java that some of the other new JVM languages have. Moreover, it's well-supported by IntelliJ and consequently by Android studio.
I'm surprised you were downvoted. I think this suggestion makes a ton of sense. It's certainly the shortest path to having a significantly improved first-party language for Android and Google does have a working relationship with Jetbrains.
That would be neat and a very pragmatic choice, but I'm not sure that Kotlin provides enough of an advantage over Java to make migrating worth for a significant amount of Android developers. Scala goes a step or two further, but the overhead (cognitive and at runtime) are a problem too.
Agree. Kotlin is pretty much Java 8 with Scala syntax. It's neat, but mostly useless.
If Google wanted to stay conservative, they could just support Java 8, but if they wanted something considerably superior ... well, Kotlin is not participating here.
But hey, Google sucks so much at programming languages (see Go and Dart) that I don't expect that they do anything that makes sense for developers.
Agree. Kotlin is pretty much Java 8 with Scala syntax. It's neat, but mostly useless.
It does contain many features people have been asking for in Java for years, but that Java 8 does not provide, such as: properties, mixins, type inference, pattern matching, operator overloading, etc.
Also, I assume that JetBrains would be open to other features that Google would like in a Java-replacement.
At any rate, all JVM languages, including Scala are going to be limited by the VM and bytecode. So, you'll have to live with type erasure, without your own value types, etc.
> Also, I assume that JetBrains would be open to other features
> that Google would like in a Java-replacement.
I could totally understand that, it would probably their last and only chance to get some users.
I don't want to sound harsh, but their situations must be quite dire right now. The language is still stuck in some 0.x-land (unlike Ceylon), Java 8 shipped with most of their features already, they are unable to compete with better languages (like Scala) and the tooling and IDE situation looks pretty bad, too.
> At any rate, all JVM languages, including Scala are going to be
> limited by the VM and bytecode. So, you'll have to live with type
> erasure, without your own value types, etc.
Because having a VM with value types and working Generics is such an impossible feat that no one managed to implement it? I guess not.
No one is preventing them from supporting a superset of the class file format which allows value types and better Generics.
