Kotlin is exactly what Google needed to light a fire under Oracle's ass. They've been dragging their feet on new Java features for years. That, and the constant threat of Oracle closing Java back up as they're doing to MySQL.
The backlash against jigsaw may turn out to be justified. "Modularizing" the JVM would be exactly what you would expect as a first step to making some parts proprietary. If Oracle can wall off parts of the JVM completely they can claim GPL exemption for these parts and start closed source development of "enterprise" level features.
Kotlin will do a lot to derail attempts to make Java proprietary. Since it works fine on Java6 JVM's it sends a strong signal to Oracle that "we don't need you, if you piss us off we'll just fork the language".
To be fair, Oracle released Java 7 and especially Java 8 with a bunch of goodies and improvements that increased productivity and brought new paradigms to the language in an elegant way (considering it's still Java). But Google already de-facto forked the language a long time ago for use in Android, so these improvements were nowhere to be found in Android for a long time.
The mention of Jigsaw is a red herring. Jigsaw, after long years of design-by-committee, suddenly devolved into a proxy war between enterprise players invested in existing module solutions. It's not about making parts proprietary at all; rather, it's about protecting existing investments in modularization ecosystems, the kinds of which form an important part of several companies' business models, all interspersed with legitimate technical and practical concerns about how to be prescriptive without being overly restrictive. The concern whether parts of a Java implementation can be made proprietary doesn't depend on the Jigsaw question, because there are several Java implementations today that are proprietary in part or whole, ranging from mediocre to marvellous, and they still manage to attract clientele.
However, I do agree that Kotlin is a signal to Oracle. It's a signal that Google has given the Android programming question, and the Java question a good amount of thought, and may have found a way to slowly transition off of a technology whose use literally resulted in them being sued, outcome notwithstanding; with Kotlin they can leverage compatibility with the lowest levels of the Java platform (and thus, all existing Java-coded Android code), give people a modern language that offers niceties and high productivity -- all courtesy of a partner whose interests align well with those of Google, and with whom they have cooperated before.
With Kotlin, Android can migrate off of Java without throwing away their existing investment in the body of code that happens to run on Android today, and do so in a way that makes it likely that developers will migrate voluntarily, vs. being forced.
I think the Kotlin Android phenomenon is really more a result of Android developers being unhappy with Google's stewardship than they are with Oracle's.
They can make proprietary distributions of JVM right away. I don't see how jigsaw can change it. As far as I understand, copyright for JVM belongs to Oracle, and they can distribute it with whatever license they want without any problem.
Android has not incorporated most of Java 7 or 8's new features so I don't think the pace of Java features has anything to do with the Kotlin adoption.
Kotlin is such a small thing for Oracle or Google. None of them will care much about it. Kotin in Android land works only on JVM like DalvikVM thing which was part of dispute between Oracle and Google. Other API copyright dispute will also remain same because Google has not written grounds up new APIs in Kotlin for Android and planning to move everyone to that.
I guess at this point many just do not understand the enormity of Java in industry and Android in particular. Kotlin is welcome addition to Android but thinking it can challenge Java is like Nerf toys can challenge Nuclear powers.
>If Oracle can wall off parts of the JVM completely they can claim GPL exemption for these parts and start closed source development of "enterprise" level features
Why does Oracle need a GPL exemption on source code they own?
"what Google needed to light a fire under Oracle's ass" What a strange sentence. To be clear: Kotlin is created by Jetbrains (makers of IntelliJ and Resharper).
And why in the world would Google want to light a fire under Oracle's ass? Perhaps I'm missing something...
Oracle has been dragging their feet on adding new language features and their developer base is getting tired of the extremely long wait times. Having to wait until 2020, or longer, for values types, generic specialization and a proper FFI is ludicrous especially when you consider that these features could have arrived in Java 9 had it not been for the prioritization of Project Jigsaw.
As for Oracle trying to close Java - any attempt to do so would be a disaster. IBM, Red Hat and other major players in the Java space would organize and fork the language.
TL;DR -- because developers love it. I clicked the article hoping there was some strategic background, some connection to the Oracle lawsuit, etc. Nop, the answer to "why" is "because of its merits". Also in this article, some backstory about the name "Kotlin".
I wonder if the hn gods will change the title from "Why supporting Kotlin is genius move for Android" to something less sensationalist. Maybe not, as it's being posted by Steven Levy himself.
* Developers are adopting it to begin with, without the announcement, locally to Orlando it's a rising language for Android developers, nobody's forcing the language on them, they try it, like it and bam.
* Oracle lawsuit makes it a no brainer to accept other languages into the Android stack that could get them off their back.
* Kotlin native would allow Android to maybe someday ditch the Java based VM altogetherm potentially.
The tooling is also great and the language seems to be rather healthy.
The language is indeed very nice but really key things that make it so nice are also:
1. The IDE support (without it, it would be somewhat more painful)
2. The fact JetBrains have built a really great new syntax and still have it compile down to regular java bytecode - and bytecode that isn't a total nightmare (I'm looking at you Scala!)
3. JetBrains use it themselves for their own suite of commercial products (mostly code editors) - this made me feel like it was less likely to become a toy language.
4. The fact that coming from Java it is absolutely painless - familiar syntax, automatic code conversion that works well for the most part, and full interop with Java.
> In the early 1700s, Peter the Great, the czar of Russia, was busy nabbing land from his western neighbor, the Swedish Empire. He seized the tip of the Gulf of Finland, and began building his beloved city of Saint Petersburg there. He also secured a small island just off its coast as a naval defense: Kotlin.
> Peter couldn’t have known that more than three centuries and 5,500 miles removed...
However, if you are from eastern Europe, chances are you've ran into large brand of tomato products known by same name:
Exactly this. So tired of these self-entitled feeling-smart conspiracist unnecessary interpolation of unrelated events, e.g. Oracle lawsuit, Google's agenda blahblah.
Kotlin is already popular in Android dev crowd. That is the one and foremost factor that why Google would support it. Because there is already a community and a robust toolchain(Thanks to Jetbrain) over there. It is a low-hanging effort for Google to claim by simply signaling a gesture with very little to commit really.
Kotlin is already quite popular in the Android community. I would actually point out that it is the engineers at Square (like Jake Wharton) that gave Kotlin it's early legitimacy.
The Google announcement excites me for reasons beyond Android - I'm hoping that Google's huge investments in machine learning, play off along with the amount of investment it is going to do in Kotlin.
I would love to see a whole bunch of server side infrastructural components built out in Kotlin ... including things like Tensorflow, Spark, etc
More than Oracle, I think this is pretty much the death knell for Scala. When you have a far more pleasant language, with IDE integration that is mind blowing, and is supported by one of the largest companies in the world ... And probably is ALREADY MUCH MUCH more popular than Scala at this point
We'll see how Kotlin looks when it's as old as Scala is. They haven't yet had to make substantial changes while keeping compatibility with existing codebases; that's hard for any language and much harder for a language that throws in a lot of ad-hoc special-case features at the language level (which Kotlin does a lot more than Scala, despite how it might superficially seem).
I'm glad to see Kotlin support (would love Python support but you can't win them all)
The Android APIs are still a major problem for me. In web front-ends we've basically gone full FRP and I'm sitting here with my resource files and 10 line invocations to make a notification.
This is partly because it's necessary for Java, but I'd love to see a first party API that tries out something a bit more fluent
It's not necessary for Java, the Android APIs are just horribly written, and the notification is a lot more involved than you'd think because it ties into how the OOM treats your app and the intent system
frp on the front end varies widely. it's trending towards a true vision but something like Cycle hasn't completely enveloped the mainstream's mind. IMHO, Microsoft and FB need to lead the way on this complete transition on the web
Check out Litho, it's built around the principles of declarative APIs and one way data flow with immutable props. Definitely taking inspiration from React.
The way I see it - the fact that alternative JVM languages are so underused is a damn shame. And if it becomes more acceptable to not use Java, then all such languages will benefit. For many reasons Kotlin is better as a champion of such a change.
Probably a silly question, but since Android is OSS, what specifically prevents parties other than Google from adding "first class" language support?
Does Google not accept (major) external contributions to the build toolchains? Is it the official documentation that's getting rewritten for Kotlin? Or is Google releasing Kotlin-ified wrappers for the Android APIs? Maybe I don't fully understand what new privileges Kotlin is getting.
The Android APIs are all pretty much Java, so you need a JVM langauge to use them. The NDK requires a Java shim layer, and then you end up writing Java anyway to use most platform features.
Google obviously won't support competing first class toolkits on Android. You can already use most JVM languages on Android as is, especially since the switch to OpenJDK. Giving Kotlin first class support is just adding it to their own in house tools. You can already use Scala, for example, if you want.
Qt is a great example of how hard it is to bring a 3rd party language to Android. Qt app on Android cannot use native theme, cannot interact with most other apps, don't behave like other apps perfectly, and can be a mess to deploy because of how many Qt libraries you need to bundle in. Google doesn't actively stop you from shipping a Qt app on Android, but it took the Qt company a lot of work to get support where it is now, and its still far from seamless (if you want an example of a great Qt on Android app, try Subsurface Mobile that uses the Kirigami widget set).
Kotlin is getting Google's blessing. Mentioned in Google's Android development docs and tutorials. That's the magic sauce. Since Kotlin is veeery close to Java, it was already working well on Android. It targets the JVM of Java6, so if you compile your Kotlin android app, it looks like a regular thing compiled from Android Studio. Regular bytecode, that then gets recompiled by dx (dalvik compiler into .dex bytecode - see also https://softwareengineering.stackexchange.com/questions/2852... )
And yes, adding new things to Android is ... problematic, because Google doesn't accept pull requests. (It accepts bug reports, and sometimes patches of bugs.) And of course you can propose a big patch adding [see https://source.android.com/source/life-of-a-patch ] .. let's say Swift to the Android Platform, but the project owners are Google employees, and the community cannot really influence what gets accepted. [ https://source.android.com/source/roles ]
Ever since amazon managed to making a competing Android release with everything Google stripped out, the SDK licenses have intentionally been made very onerous, it's become nearly impossible to get your own SDK extensions put into the SDK manager, and Google has been moving as much as possible into private extensions like Google Play Services. They even strong armed cell companies into breaking contracts with GPS provider replacements, like SkyHook.
I worked for an OEM at the time Google kicked us out of the SDK manager update list, so am familiar with the about face. If you do try to make your own toolkit, you'll have to fight very hard to do so. JetBrains writes IDEs and licensed Android Studio to Google, so there's no harm in Google helping them, but anyone else would be in for a lot of pain.
I'm sure Kotlin is a good language but as a developer with a big codebase I find it difficult to migrate my Java code to Kotlin or mix both languages in the same project. I think I will be confused all the time!
If I would be starting with the platform now I'd start with it but now I dont see any reason!
Now more I think about It is genius move by Google. With this low effort work Google generated lot of buzz. Android remain same. Tooling and language is developed by Jetbrains for Kotlin. If Kotlin brings in new developer to Android, great for Google, if not, dependable Java is always there.
So how is Kotlin's interop with native code? I heard it was still pretty bad with Java despite some updates in that department. Swift can handle some API's but for real interop you can go back to Objective-C(++) wrappers with zero penalty.
I wonder if Kotlin could compile to Dalvik bytecode in the future? It might be pointless with Java, because Oracle owns Java compiler and maintaining separate fork might prove hard to do. But with Kotlin it should be somewhat easier. I've heard that the whole Android development is very slow because of those intermediate steps.
Also it might help to develop or improve live update features. If I'm developing server applications, I'm usually using JRebel which allows live reloads of bytecode and that's tremendous productivity gain. Same with React Native. I'm not sure about pure Android development.
Seems to be about the same as Java. The main source of slowness when compiling is, as always, Gradle and not the compilation itself. Kotlin doesn't fix that.
[+] [-] slackingoff2017|8 years ago|reply
The backlash against jigsaw may turn out to be justified. "Modularizing" the JVM would be exactly what you would expect as a first step to making some parts proprietary. If Oracle can wall off parts of the JVM completely they can claim GPL exemption for these parts and start closed source development of "enterprise" level features.
Kotlin will do a lot to derail attempts to make Java proprietary. Since it works fine on Java6 JVM's it sends a strong signal to Oracle that "we don't need you, if you piss us off we'll just fork the language".
[+] [-] niftich|8 years ago|reply
The mention of Jigsaw is a red herring. Jigsaw, after long years of design-by-committee, suddenly devolved into a proxy war between enterprise players invested in existing module solutions. It's not about making parts proprietary at all; rather, it's about protecting existing investments in modularization ecosystems, the kinds of which form an important part of several companies' business models, all interspersed with legitimate technical and practical concerns about how to be prescriptive without being overly restrictive. The concern whether parts of a Java implementation can be made proprietary doesn't depend on the Jigsaw question, because there are several Java implementations today that are proprietary in part or whole, ranging from mediocre to marvellous, and they still manage to attract clientele.
However, I do agree that Kotlin is a signal to Oracle. It's a signal that Google has given the Android programming question, and the Java question a good amount of thought, and may have found a way to slowly transition off of a technology whose use literally resulted in them being sued, outcome notwithstanding; with Kotlin they can leverage compatibility with the lowest levels of the Java platform (and thus, all existing Java-coded Android code), give people a modern language that offers niceties and high productivity -- all courtesy of a partner whose interests align well with those of Google, and with whom they have cooperated before.
With Kotlin, Android can migrate off of Java without throwing away their existing investment in the body of code that happens to run on Android today, and do so in a way that makes it likely that developers will migrate voluntarily, vs. being forced.
[+] [-] the_trapper|8 years ago|reply
The Google that still doesn't support all of Java 8 on Android?
https://developer.android.com/studio/preview/features/java8-...
I think the Kotlin Android phenomenon is really more a result of Android developers being unhappy with Google's stewardship than they are with Oracle's.
[+] [-] 0x0|8 years ago|reply
[+] [-] solomatov|8 years ago|reply
[+] [-] guelo|8 years ago|reply
[+] [-] geodel|8 years ago|reply
I guess at this point many just do not understand the enormity of Java in industry and Android in particular. Kotlin is welcome addition to Android but thinking it can challenge Java is like Nerf toys can challenge Nuclear powers.
[+] [-] macspoofing|8 years ago|reply
Why does Oracle need a GPL exemption on source code they own?
[+] [-] pjmlp|8 years ago|reply
Plus you are forgetting that everything still runs on top of Java and the JVM, just the code on the actual devices does not.
[+] [-] danesparza|8 years ago|reply
And why in the world would Google want to light a fire under Oracle's ass? Perhaps I'm missing something...
[+] [-] mrnaught|8 years ago|reply
[+] [-] bitmapbrother|8 years ago|reply
As for Oracle trying to close Java - any attempt to do so would be a disaster. IBM, Red Hat and other major players in the Java space would organize and fork the language.
[+] [-] davidf18|8 years ago|reply
[+] [-] alexandros|8 years ago|reply
[+] [-] darwhy|8 years ago|reply
[+] [-] giancarlostoro|8 years ago|reply
* Developers are adopting it to begin with, without the announcement, locally to Orlando it's a rising language for Android developers, nobody's forcing the language on them, they try it, like it and bam. * Oracle lawsuit makes it a no brainer to accept other languages into the Android stack that could get them off their back. * Kotlin native would allow Android to maybe someday ditch the Java based VM altogetherm potentially.
The tooling is also great and the language seems to be rather healthy.
[+] [-] dom0|8 years ago|reply
[+] [-] appleflaxen|8 years ago|reply
mods: can we get this changed to the original title?
i don't know if it's fair or not, but it feels like there is somebody making a really concerted effort to astroturf kotlin.[+] [-] jarym|8 years ago|reply
1. The IDE support (without it, it would be somewhat more painful)
2. The fact JetBrains have built a really great new syntax and still have it compile down to regular java bytecode - and bytecode that isn't a total nightmare (I'm looking at you Scala!)
3. JetBrains use it themselves for their own suite of commercial products (mostly code editors) - this made me feel like it was less likely to become a toy language.
4. The fact that coming from Java it is absolutely painless - familiar syntax, automatic code conversion that works well for the most part, and full interop with Java.
[+] [-] smt88|8 years ago|reply
[+] [-] Ralfp|8 years ago|reply
> Peter couldn’t have known that more than three centuries and 5,500 miles removed...
However, if you are from eastern Europe, chances are you've ran into large brand of tomato products known by same name:
https://maspex.com/files/pl/news_spotlight/file_57502ce3e538...
;)
[+] [-] tanilama|8 years ago|reply
Kotlin is already popular in Android dev crowd. That is the one and foremost factor that why Google would support it. Because there is already a community and a robust toolchain(Thanks to Jetbrain) over there. It is a low-hanging effort for Google to claim by simply signaling a gesture with very little to commit really.
[+] [-] sandGorgon|8 years ago|reply
The Google announcement excites me for reasons beyond Android - I'm hoping that Google's huge investments in machine learning, play off along with the amount of investment it is going to do in Kotlin.
I would love to see a whole bunch of server side infrastructural components built out in Kotlin ... including things like Tensorflow, Spark, etc
More than Oracle, I think this is pretty much the death knell for Scala. When you have a far more pleasant language, with IDE integration that is mind blowing, and is supported by one of the largest companies in the world ... And probably is ALREADY MUCH MUCH more popular than Scala at this point
[+] [-] lmm|8 years ago|reply
[+] [-] manojlds|8 years ago|reply
[+] [-] zzalpha|8 years ago|reply
[+] [-] hoodoof|8 years ago|reply
[+] [-] throwaway7645|8 years ago|reply
[+] [-] rtpg|8 years ago|reply
The Android APIs are still a major problem for me. In web front-ends we've basically gone full FRP and I'm sitting here with my resource files and 10 line invocations to make a notification.
This is partly because it's necessary for Java, but I'd love to see a first party API that tries out something a bit more fluent
[+] [-] BoorishBears|8 years ago|reply
[+] [-] zghst|8 years ago|reply
[+] [-] krschultz|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] grzm|8 years ago|reply
[+] [-] xaduha|8 years ago|reply
[+] [-] bogidon|8 years ago|reply
Does Google not accept (major) external contributions to the build toolchains? Is it the official documentation that's getting rewritten for Kotlin? Or is Google releasing Kotlin-ified wrappers for the Android APIs? Maybe I don't fully understand what new privileges Kotlin is getting.
[+] [-] zanny|8 years ago|reply
Google obviously won't support competing first class toolkits on Android. You can already use most JVM languages on Android as is, especially since the switch to OpenJDK. Giving Kotlin first class support is just adding it to their own in house tools. You can already use Scala, for example, if you want.
Qt is a great example of how hard it is to bring a 3rd party language to Android. Qt app on Android cannot use native theme, cannot interact with most other apps, don't behave like other apps perfectly, and can be a mess to deploy because of how many Qt libraries you need to bundle in. Google doesn't actively stop you from shipping a Qt app on Android, but it took the Qt company a lot of work to get support where it is now, and its still far from seamless (if you want an example of a great Qt on Android app, try Subsurface Mobile that uses the Kirigami widget set).
[+] [-] pas|8 years ago|reply
And yes, adding new things to Android is ... problematic, because Google doesn't accept pull requests. (It accepts bug reports, and sometimes patches of bugs.) And of course you can propose a big patch adding [see https://source.android.com/source/life-of-a-patch ] .. let's say Swift to the Android Platform, but the project owners are Google employees, and the community cannot really influence what gets accepted. [ https://source.android.com/source/roles ]
[+] [-] lnanek2|8 years ago|reply
I worked for an OEM at the time Google kicked us out of the SDK manager update list, so am familiar with the about face. If you do try to make your own toolkit, you'll have to fight very hard to do so. JetBrains writes IDEs and licensed Android Studio to Google, so there's no harm in Google helping them, but anyone else would be in for a lot of pain.
[+] [-] izacus|8 years ago|reply
[+] [-] fooker|8 years ago|reply
Won't the platform APIs designed for Java look and feel very non-idiomatic in Kotlin?
[+] [-] victornomad|8 years ago|reply
If I would be starting with the platform now I'd start with it but now I dont see any reason!
[+] [-] geodel|8 years ago|reply
[+] [-] edzo|8 years ago|reply
[+] [-] dep_b|8 years ago|reply
[+] [-] vbezhenar|8 years ago|reply
Also it might help to develop or improve live update features. If I'm developing server applications, I'm usually using JRebel which allows live reloads of bytecode and that's tremendous productivity gain. Same with React Native. I'm not sure about pure Android development.
[+] [-] yawaramin|8 years ago|reply
[+] [-] lokedhs|8 years ago|reply
[+] [-] xaduha|8 years ago|reply
https://github.com/tumblr/colossus
[+] [-] wheelerwj|8 years ago|reply
edit: so i checked this out myself. i have no idea why this is a big deal. another app language? i thought reactnative was all the jazz?