> 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:
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.
There is no single Java VM. There's a specification with a significant number of different implementations, and the OpenJDK-based one is far from the only one in use today.
Also code is still compiled to the same format that the Dalvik VM consumed. ART is just a different system for getting from Java bytecode to something executable.
so if kotlin can bring java 8 features/improvements to a platform that is stuck on an older JVM (and not even the "true" JVM, but another implementation of it), then does that mean these features are not dependent on the runtime? If that's the case, these "java 8" features could be implemented into the Java language without needing to change the runtime?
If that is true, why are these changes not being brought to Java itself, if they can be done without a change to the runtime?
I'm not sure if this is the case, but often it is _possible_ to implement something in, e.g., the stdlib, in a way that is _functional_, but with the right VM support it might be much more performant.
Take for example Lambdas. Android has no invokedynamic, so every lambda has to be compiled to a class with a method. Android only allows 65k methods overall per linked unit, so that quickly becomes an issue.
Kotlin, on the other hand, can do much more intelligent transformations (look at its inline functions).
Kotlin is far simpler than Scala which has a big emphasis on functional programming and OO, so not going to be super popular soon. It's also behind Kotlin in good ide support. Clojure is simpler, but mainly focuses on functional programming and is a lisp as well, so will also not be a great candidate for the masses.
Functional programming has surged strongly in popularity these last couple of years.
As pointed out, other JVM languages also have "Java interoperability" as top priority. Clojure does.
Clojure is getting popular lately, why isn't a "great candidate for the masses"? Because it is a Lisp? During most of the 1980s, the #1 programming language to teach children how to program was LOGO, which is basically Lisp in disguise...
If something doesn't have algol syntax, it generally doesn't do well with the masses. Look at where Common Lisp & Clojure sit on the TIOBE list(do they even break the top 20?) FP is picking up some steam, but I fear lisp never will especially with such fragmentation of language and vendor. I'm not really familiar with Logo, but it doesn't sound like it had parenthesis or brackets like Rebol (something to make it homoiconic), and since it is not in use anymore...that might be proving my point.
C, C#, C++, Java, & JS could be said to have a derivative of Algol syntax. That covers probably 90% of all software being actively written in the world.
Yes, it'll be non-idiomatic, not very non-idiomatic, because Kotlin is not that far from Java. Kotlin is better than Java even for consuming Java API. And you can write Kotlin wrappers around this API to make it better.
I've written few Kotlin applications. I didn't use Kotlin libraries, I used only JDK and Java libraries. I never felt that I would be better using Java. Kotlin is better in every aspect or at least not worse.
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.
It has very smooth interop, both languages can call each other's methods with no fuss. You can mix and match kotlin and Java files in the same directory. There are one-click tools for auto converting Java to kotlin. It is probably the main reason it beat out Scala on Android, along with the small runtime and superior IDE support.
Kotlin Native (Kotlin <-> C & Objective C) just came out this month, is still a technology preview, and AFAIK is really rough around the edges. Haven't tried it.
Kotlin has always had a very good Java interop story, in both directions. I've been using it for a year with Hadoop, AWS, JSoup, Rome, Jackson, DropWizard, Jetty, Apache Commons, ElasticSearch, Weka, and many other standard Java libraries and never had a problem. You basically drop in a library and go. Several of those libraries are either really old (eg. Weka was written in the last millenium) or pretty complex (Jackson is all annotation/reflection based), and I've never really had a problem. You do need to keep track of nulls yourself when crossing the Java boundary, and you need to understand what code Kotlin generates if you're implementing an interface or placing annotations, but both of those are well-documented and pretty typical tasks for any FFI work.
Yeah, for this project at least. I've found that my choice of technology stack is largely dictated by a.) the libraries that are available and b.) the potential market I'm investigating. It's in Kotlin because I need Hadoop for at least part of the project, and one corpus I'm working with has a bunch of supporting tools in Java that aren't available on other platforms.
I'd been doing a bunch with smartwatches a year or two back, so the project before this was in Swift (because when I talked to potential customers & looked at market share numbers, starting with anything other than the Apple Watch was indefensible), and two projects before then were in Java (because the Apple Watch wasn't out yet and Android Wear & Pebble were the only games in town). There were also a couple ideas that I'd tested out using just WordPress and YouTube, with no coding at all.
Interop is dictated by the JVM itself - the whole point of JNI is that it translates data types into native types and properly manages access and lifecycle of objects that are otherwise owned by the JVM GC.
Kotlin doesn't change any of that - you still need to go through JNI bridge and properly mark and pin objects as they're being owned by the other language.
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!
Hit this on an iOS project moving from Objective C to Swift, and it wasn't that hard. We just made the decision that whenever we were doing substantial work in a class, we'd move that class to Swift. It had the side benefit of getting ahead on some tech debt/refactorings because moving to a different language was the right time to make those kinds of investments.
Another iOS developer here. Maintained both swift and Objective-C code in multiple apps. Never felt that was a big issue. Perhaps different for us iOs developers as we knew/know it is just a question of time before everybody had migrated to Swift.
It looks to me like Kotlin is enough like enhanced Java that it's pretty painless to extend an existing Java codebase with it. IntelliJ even has automatic translation of Java source files to Kotlin, though I'm sure there are edge cases where that doesn't go well. The benefit is not having to write Java anymore. If you don't mind writing Java then I think you might benefit from exposure to a wider variety of languages.
As for getting confused between languages, most of us work in heterogeneous environments these days, even if it's just something like using Python server-side and Javascript client-side. I don't find confusion over the languages to be a significant difficulty there and I don't think it would be with a mixed Java/Kotlin project.
I feel the same way. I may try and implement some Kotlin on my next Android project, but I don't have a compelling reason to merge it into anything existing. Plus, I find Java just fine to work with.
Swift was a giant improvement on Obj-c, imo. It was apparent in every way when I first looked at the language. I'm not getting that same vibe here with Kotlin.
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".
I have no hard evidence of this but it seemed like the most logical explanation. Oracle won't let Jigsaw die after many years of debate, it's really important to them for some reason.
On the other end, some people in the community seem willing to sacrifice their position on the community board to stop Jigsaw.
There doesn't seem to be any consensus on exactly what makes Jigsaw bad and everyone seems to have their own laundry list of reasons. Even stranger, the use cases and utility of Jigsaw seem limited to just about everyone as the existing package system is quite good.
So why is there so much pushing from both ends? Maybe something isn't being said because it would damage the relationships between Oracle and Java sponsors. It's one thing to say "I don't like this module system for these technical reasons". It's another thing entirely to say "I don't trust your company to keep important parts of the JVM on the GPL".
A large java partner company accusing Oracle of closing off Java would make big waves in the community that would hurt both parties. Much better to just cause these initiatives to fail by political means.
This is just baseless accusations and speculation.
Jigsaw is important for everyone in the community (less so for Oracle actually) because it reduces the startup time and memory footprint of the JVM. This enables it to be used in more places and on more devices and benefits all of the JVM languages in one hit.
The issues raised within the JSR group have been transparently raised and are purely technical and ideological. There could be a commercial aspect but really it's irrelevant. Red Hat, IBM etc do not depend on OSGi or other module systems for their commercial success. Any ulterior motives really don't make much sense.
The main entity with commercial interest in splitting up the JVM is Oracle. Jigsaw was originally just a plan to split up the runtime into components and the module aspects were added later. OpenJDK is now being used by Google on all Android devices and Oracle is probably furious that there's no way to extract licensing fees from this arrangement. To me that sounds like plenty of ulterior motive.
OpenJdk has a linking exemption which would allow Oracle to develop closed source extensions to the JVM if it was built in a modularized way. Why else would Oracle continue to push something that's been so controversial for years? The only explanation I can think of is that it would allow them to put other more profitable plans into motion.
It's definitely speculation but not totally baseless. Oracle has been increasingly aggressive about monetizing Java in the last few years. I don't think it's unreasonable for them to add language features to increase their ability to make money from Java licensing.
Modularizing the JVM has many benefits. Unfortunately, as part of that process they ended up with a much bigger scope than we had all anticipated. Enforcing a new [mandatory] module system for all third-party code - with significant compatibility concerns and very few benefits is another.
Module systems sound great in theory. But we already have a bunch of existing ones, some simple and ad-hoc (like how we package things into JARs, publish to Maven Central or another artifact repository and load using regular old classloaders) and some are very formal and complex (OSGi or any of the big J2EE Application Servers).
> it reduces the startup time and memory footprint of the JVM
How so? There is additional machinery needed to be started, the module system, and additional checks needed to be performed (module access) and additional metadata to be kept at runtime (module metadata). How is that helping startup time and and footprint? If anything that should make it worse.
Class loading has been lazy since day one, so if you don't use CORBA then CORBA classes are not loaded. This has been the case since Java 1.0.
JVM startup time is actually pretty good. If your application takes seconds to start that's because your startup code takes seconds to run. Jigsaw isn't going to help you there.
Nope, that's an entirely proprietary, intentionally unspecified extension.
> it is possible to create a JRE for distribution having only the code that actually matters for the application.
I don't see how this reduces the startup time and memory footprint of the JVM. If a class is not needed by your application it's not loaded, that has been the case since Java 1.0. I don't see how it not being present on disk makes any difference.
> It is also part of how the upcoming AOT compiler to native code will work.
Nope. It also works on classes and plain old JARs [1]
Jigsaw was started by Sun before Oracle even involved in Java. I know because supporting Jigsaw was on my radar - in 2008. I don't know where you are getting this conspiracy theory that Jigsaw is sinister move by Oracle. It's going to solve some of the worst aspects of the JVM (startup time, distribution). The reason it has taken so long is because it is technically difficult and there was a 2-3 year stall in JVM progress after Oracle's acquisition of Sun.
Because the JVM is much higher level, including object-oriented bytecode letting you jist say "invoke method X on this object", which can in turn be inlined by the JVM using appropriate guards. With LLVM, you'll be forced to "get virtual base class C, read address of method X, jump to location" on every single method call. Not to mention all the array bounds checking which the JVM can remove once it can prove that you're not going outside the bounds. Oh and when debugging you automatically get the unoptimized version of the code when stepping through methods, which I think LLVM can't do (dynamic deoptimization)
Edit: the question is moot for Android, since it never used the JVM anyway, but the question is still sensible if you interpret it as "why use high level object oriented vm instead of low level vm"
To get an idea of how much work is involved in getting LLVM to run a high level language, take a look at Clasp, which does exactly this. It's not a small project and it's definitely not an easy thing to do.
I'm completely unclear on what point you are trying to make here.
The parent was about what LLVM can and can't do.
I pointed out it does all the things the parent says it can't, and was made to do those things relatively quickly.
I gave a link showing it gives 5-250% better code than hotspot while doing so.
I'm not sure what relevance the existing execution platform would have to any of that.
As far as I can tell, it has "none".
Among other reasons, what the last tier compiler does has to be better than the other tiers, or it's a pointless waste of time. It's not like it can generate worse code and you can get away with it.
It also was not built in a way that requires their jvm execution platform, or anything like that.
You could take it and hook it into another JVM if you wanted, in roughly the same time frame.
The only difference is that instead of pretending it's hard or impossible, they just did the hard work to do it.
If the point you are trying to make is that you can't use it as a first tier or second tier jit, and that it would never work without some magical existing jvm technology, this would also be wrong.
"and have been building JVM execution environments for over a decade, you mean"
The folks involved had not.
Really.
I feel like you are just going off on a random tangent without a lot of data here, just because you don't want to say "yeah, i guess the parent was wrong".
I could also point out that LLVM is just about as old as Hotspot, for example (1999 vs 2000), and both are a decade older than Azul's compilers (2010).
> I feel like you are just going off on a random tangent without a lot of data here, just because you don't want to say "yeah, i guess the parent was wrong".
Okay, but, uh... having never been involved in the conversation until that point, I could have just... not said anything about the parent? It just sounded like you were trivializing something which likely wasn't an easy thing to do.
Link? Superior in what way? Is there any LLVM based JVM implementation that runs faster than the current JVM android is using and no compatibility issue?
When I see those claims without any actual code, I would stay suspicious and call it farce, until it proves itself.
"Link? Superior in what way? Is there any LLVM based JVM implementation that runs faster than the current JVM android is using and no compatibility issue?
"
Yes.
Azul uses LLVM as its last tier JIT compiler now :)
I don't think anyone is going to argue they don't have the fastest JVM around.
The performance numbers they give are:
" Falcon bests Oracle's HotSpot Java platform by anywhere from 5 to 250 percent in production performance, depending on the application, according to Azul. "
And you forget to quote:
> Based on the LLVM compiler platform, designed for server workloads, and optimized for recent Intel and AMD architectures
Server and mobile application have vastly different assumption of workload and metrics to take a look at. However, this announcement definitely better than OP's vague performance claim, which I agree. But as I said, there is no proof at this point, that LLVM based implementation on Android improve the the performance.
And it was never used as the primary option anyway. So there is definitely not enough confidence to claim the superiority, until somehow make it work in the first place.
It can end up with direct code generation. No JIT, no interpreter, no loading a "JVM." C++ (Clang) generates LLVM, not JVM. So does Rust. Two languages where performance is a requirement. As other have pointed out, any optimizations that can be preformed by the cumbersome JVM can be preformed in LLVM. But in addition, instead of using registers, the JVM uses variables on the stack frame. Why use slower hardware than the build in registers? Then there is that automatic garbage collection which can interrupt a processor randomly.
Using a JVM or CLR by MS (who with C# was making their own Java) seems cumbersome compared with direct code generation with the LLVM as intermediate code.
Apple derives $150 billion per year as an iOS phone headset company and it chose to use LLVM years ago when the processors were not nearly as powerful as today. When an Android headset even with good hardware would require 1 GB RAM, iPhones could run with better performance on 500 MB.
> any optimizations that can be preformed by the cumbersome JVM can be preformed in LLVM
That cumbersome JVM can optimise based on runtime knowledge of the characteristics of the running code. In many cases, that kind of optimisation is more effective than the static compile-time sort.
I am curious as to what exactly can be optimized by the JVM runtime vs. LLVM. Do you mean targeting specific machine architectures? Because LLVM can generate images for different processors (e.g., different version of Intel architectures).
Android devices after 5.0 (when ART was introduced) precompile ~~JVM~~ Dalvik bytecode to LLVM on the way to native code. If you want to deploy native code that was compiled via LLVM, you've been able to do that for a while.
The native API is pretty crappy, but trying to shoehorn LLVM IR into a Java bytecode replacement (which is not an easy task, see PNaCl) doesn't do anything to help.
Edit: ART handles Dalvik bytecode, not Java bytecode.
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.
The story is not as simple as it seems on the surface. Google used Apache Harmony which was discontinued because Oracle would not give Apache a TCK license. Without being able to run the Technology Compatibility Toolkit, Apache Harmony could not become a certified compatible Java implementation. This would greatly limit usage, so Apache pulled the plug on the project.
Oracle killed Apache Harmony which is how Android got "stuck" at Java 6.
I did not know that Android's 'stuck at Java 6' situation was due to the Apache Harmony project-Oracle scuffle.
Statement by the ASF Board on our participation in the Java Community Process:
> Through the JSPA, the agreement under which both Oracle and the ASF participate in the JCP, the ASF has been entitled to a license for the test kit for Java SE (the "TCK") that will allow the ASF to test and distribute a release of the Apache Harmony project under the Apache License. Oracle is violating their contractual obligation as set forth under the rules of the JCP by only offering a TCK license that imposes additional terms and conditions that are not compatible with open source or Free software licenses. The ASF believes that any specification lead that doesn't follow the JCP rules should not be able to participate as a member in good standing, and we have exercised our votes on JSRs -- our only real power on the JCP -- accordingly. We have voted against Sun starting and continuing JSRs, and have made it clear that we would vote against the JSR for Java SE 7 for these reasons. https://blogs.apache.org/foundation/entry/statement_by_the_a...
This saga goes back to Sun Microsystems and Apache Harmony. Harmony, as originally announced was to be an Apache 2.0 License cleanroom reimplementation of the Java platform, complete with the standard library and a VM [1]. There was a lot of confusion [2] going forward, because copyleft folks like GNU were working on Classpath, a similar project, under the GPLv2, and none of that code was license-compatible with the Apache License. This was one of the high-profile catalysts of the harmonization of open-source licenses that happened later, contributing to the future GPLv3.
Harmony ran into plenty of other challenges, but despite the odds it managed to produce a working J2SE 5 implementation. It was speculated that Sun was theoretically okay with a copyleft open source Java, but not one that wasn't copyleft, like Harmony. Specifically, they laid out conditions in the license for the Java Compatibility Kit, the conformance test suite needing to be passed to claim that you're "Java", that disallowed certain "Field[s] of Use" i.e. natures of deployment [3][4].
The "Field of Use" restrictions that Sun has imposed restrict software certified with the TCK to "general computing devices" which would for instance restrict use on kiosks or mobile devices. [5]
The Field of Use restrictions limiting J2SE 5 implementations to "General Purpose Computing Devices" and excluding special-case appliances, kiosks, mobile computing devices and other interesting applications constitutes an "additional restriction" that would be unacceptable to us (the ASF), and equally to the FSF (by the GPL's no-additional-restrictions policy). [6]
Oracle initially supported Apache on the matter, but reversed their stance once they bought Sun [7]. Reading Sun's Field of Use restrictions heavily insinuates that covert, embedded, non-copyleft deployments -- like the future Android, a mishmash of old Harmony code, various other open source code, and closed source code -- are the exact kind of application they were hoping to curtail. Instead, Sun released OpenJDK under the copyleft GPLv2.
I meant to provide a citation for the claim that Sun was in favor of copyleft. I'm basing this on the 2007-08-09 blog entry [8] by Rich Green, then Executive VP of Software at Sun [9], which uses the word 'copyleft' explicitly. Some choice quotes from [8]:
Throughout this journey, I've slept well at night knowing that Sun has done our utmost to balance the priorities of open source communities along with the responsibilities and obligations that we have with the myriad of enterprises, individual developers and consumers who have invested in the promise of "Write Once, Run Anywhere". The choice of the GPLv2 license was and is key to this balance, because it takes away the potential for a closed fork of the code, ensuring that we can all maintain compatibility. (...)
We knew when we chose the GPL and the free software model for Java technology that we couldn't satisfy everyone's desires. This is the case for the Apache Harmony Project at the Apache Software Foundation. The Harmony Project has applied for a license to use the JCK under the JCP's Scholarship Program for qualified not-for-profit organizations. Sun has offered Apache Harmony a license to use the JCK and the Java Compatible logo at no charge once their implementation passes the tests, and were even offering free support to help Apache run the JCK. But because the Apache code is not governed by the GPL, and does not require code sharing by any entity using or modifying Harmony, the terms of this license are the same terms under which Sun licenses the JCK to commercial entities that build their own independent implementations of the Java SE platform. As was made clear in their open letter to Sun, the ASF is not satisfied with these terms. (...)
For what it's worth, I completely understand why there is disagreement. There are fundamental principles and goals that separately define the GPL and Apache Software Licenses. Unlike the GPL, the Apache open source license does not require innovation to remain in the open. Java technology governed by the Apache license could be altered by any organization -- commercial or non-profit -- and rendered both incompatible and inaccessible to the community. The trust and value of Write Once Run Anywhere could not be upheld. (...)
We believe that copyleft is both unambiguous and instrumental in fulfilling goals of both communities and commerce. (...)
One view is that they wouldn't pass it, because, in their (lawyers') own words:
Although software applications for the Android platform may be written in the Java programming language, the Dalvik bytecode is distinct and different from Java bytecode. The Dalvik VM is not a Java VM. [2]
At various points in time, certain key Google employees contemplated whether they should or shouldn't [3].
In the meanwhilr, I've veen using java 8 features on android fpr more than half a year by incorporating jack into the build system. Now this is incorporated by default and jack is no longer needed. So I'm perpetually surprised when people mention "stuck at java 6" on hn. Have you guys no first hand experience on the platform? Just chatting?
Maybe because even with Android N, one cannot use all the official Java 8 API?
And then since Android N is only 7% of the market, it means giving up on the stream libraries and the remaining features that are Android 7 only?
Finally, because lambdas are implemented with inner classes instead of new JVM bytecodes like on the real thing, Java 8 code on Android will have a performance impact?
And yes, there is also a lack of Android knowledge on HN, as many don't even know the restrictions the NDK has.
You know you can use Android N (and later) and still target Android 19 and still use lambdas, right? Or did you mean something else? Maybe the developer page confused you. Can you clarify this for me?
And yes, I know you can't use all features of java 8, but this isn't what the posts are on about. They just ignore all facts and go straight to "android is stuck at java 6" and nobody really challenges them on this belief. I guess neither will you.
I do have Android development experience, but I have more Java experience all the way back to the early JDK releases, including having read enough papers about several JVM implementations.
The issue regarding lambdas has to do how they are implemented, by making use of inner classes instead of doing what Oracle has done in Hotspot and is being followed by most third party JVM implementations, meaning making use of invokedynamic infrastructure, thus being as if there was special bytecodes for lambdas.
This allows for more performance and optimization opportunities, which are much harder to achieve with plain inner classes.
Also those of us that like Java, always mean both the language and platform when talking about Java. The current situation is that now we need to write Android specific libraries instead of being able to pick any random Java 7 or 8 library and use it on Android applications, without any change.
Just so we are on the same page, I'm on about the feature superstructure, not the "implementation details for those of us that like java and always mean hotspot-like technologies when having a conversation about android language features".
Yeah, but those implementation details are leaky abstractions about the Java 8 feature superstructure performance on Android, and what Java 8 libraries are usable straight out of Maven repositories.
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.
The upcoming release of Android studio/it's Gradle plugin support a lot of Java 8 features right out of the box. No need for plugins to patch things like lamdas
Honestly though, I think this is really more a result of the Android SDK team being drug kicking and screaming by the competition. Solutions like React Native, Kotlin, Xamarin, RetroLambda, and of course Kotlin were starting to become very viable alternatives to the official SDK.
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.
See my other comment about Java 6 on Android. Basically Oracle killed Apache Harmony which was what Android was based on. Google is now running Oracle OpenJDK which is why new features are available.
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.
Look at JavaScript, taking tinker toys and using them in the enterprise. It is impressive what people are able to do with tools like this, kinda reminds me of https://xkcd.com/1833/ and https://xkcd.com/1513/ a bit!
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.
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.
>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...
Part of the reason that Android doesn't support later Java versions is disagreements with Oracle. By supporting another language, Google is basically saying, "Play ball or we'll leave."
Eh, with Google's backing, I'd say it has reached liftoff. So far these feel like articles to attract page clicks... The substance has been seriously lacking.
Dart really deflated after it was announced it wouldn't get native support in browsers (next to JS), and energy was instead diverted to WebAssembly. It might still get a revival some years down the road with Fucsia, but we're a long way away from that - plus it would still have an Android compatibility layer I'm sure.
Dart is still better lang than JS and AngualarDart offers much better dev experience compared to React and Angular + TS (I tried all of them). Big Google apps (Ads UI) are written in Dart.
Try it out and make your own opinion https://webdev.dartlang.org/angular/
New life will come to Dart when fast Dart to JS compiler (so called DDC) will be released.
and a large part of Kotlin's inspiration is directly copied from Scala (data classes, val, var, pattern matching, sealed classes, type param on right, tuple destructuring assignment, type aliases, etc., etc.).
It would be far more accurate to say that Swift took inspiration from Scala (and Scala from ML, Smalltalk, Haskell, etc.)
And everybody takes inspiration for everything from somebody else and it can all be traced back to ancient Babylon, Greece and Rome. Yes we get it, nothing is an original idea.
Thought experiment: To be truly "original" a child that grew up with wolves in the jungle would have to come up with it (okay, not even that since it learns from the wolves). Everything else is "not truly original". Duh.
Now that we have established that no truly "original" ideas exist in any human's head (assuming "original" means going from totally empty, nothingness, to the idea), can we just get rid of all comments pointing out that X didn't really invent Y but was inspired by P?
Of course, what I just wrote isn't original in the slightest, I just don't know the names of all the people who said it before.
Well, no, Scala took inspiration from various languages of decades past and combined them together into an modern OO/FP hybrid.
Kotlin copied Scala directly, renaming `def` to `fun`, `case` to `data` and so on. There's a big difference between creating and copying.
Anyway, in hindsight it was a great idea to cherry pick from Scala as the language seems poised for much bigger things (i.e. potentially becoming a mainstream language).
Source? The Swift project's initial commit[1] was 6 months before Kotlin's initial commit[2], so I fail to see how something started six months earlier could have taken its early inspiration from a language that didn't exist yet.
Jetbrains unveiled Kotlin in 2011, it had been under development for a year at that time. Swift was introduced at Apple's 2014 Worldwide Developers Conference.
It must be pretty good. I was at the IO keynote and when they announced Kotlin support for Android, the guy sitting in front of me had to remove his sunglasses and wipe away tears of joy. Twice.
The key thing is that on mobile you are stuck with what the platform owners allow. On Android that's pretty much the JVM. You can get away with some things in native code (C, C++, now Go?), but most of the Android framework lives in the Java layer. Kotlin is pretty much your only option other than Java that works. The other JVM languages (Clojure, Scala, Groovy, etc) are quite a bit heavier and that's still an issue on mobile.
Android will eventually adopt Swift. It is not a matter of "if" but "when". Who knows 5 year from now, you all will be coding in Swift (for servers, iOS and Android).
Can you list arguments why do you believe this to be likely?
Interoperability of Swift with the existing APIs and JVM is not impossible, but it is a significant barrier that needs to be overcome and needs very, very significant advantages to justify that.
It doesn't seem to be particularly relevant; potential for server-side usage of Swift is one thing, but Swift apps for Android devices have quite different challenges and reasons for (non)adoption.
IMO, kotlin makes a much better candidate to be "the" cross platform language for server / client since it supports typescript as a first class citizen, and a native target is coming.
You could use the same arguments in the article you posted to posit that everyone will be developing on a Mac.
Swift isn't even a stable language I can't even build projects from github that are only a few months old without doing some wank-tastic manual syntax conversion or using an old version of xcode
no one wants to be held hostage to apples nuttery if it's avoidable
even .net core and it's associated languages and frameworks are in much better positions
With Kotlin on the JVM and Kotlin Native on Windows, Mac, Linux and iOS I really don't see much of a future for Swift outside of iOS. Kotlin, though, will be everywhere.
I think both will find their place. Currently there are many languages that are interchangeable in many cases and yet they find their users.
I suppose that Kotlin outside of JVM has a similar problem to Swift outside an Apple platform. You lose a support for quite a lot of already existing libraries. Rewriting everything in Kotlin and Swift will take effort and by the time we'll get there not many will want to abandon their preferred ecosystem.
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 order to implement all the Scala language magic the generated byte code is sometimes far away from what the equivalent Java code byte code would look like.
This isn't a problem for most people but it is an issue for anyone who uses stuff like byte code instrumentation - take a look at this issue for example: https://github.com/puniverse/quasar/issues/45
It's not a criticism of Scala (the language is just a LOT richer so has to cater for more sophistication).
But the difference matters to me which is why I prefer Kotlin over Scala and I'm prepared to miss out on some of that sweet Scala magic.
Kotlin was an easy win for Google. They didn't really add support for it, but merely bless the support that already existed (and with that blessing comes some assurance that things won't break for Kotlin in future versions of Android).
JetBrains was already targeting Android as a big selling point for Kotlin because Android was still on Java 6 and lacked lambdas and streams and all cool new things Java has gained. Kotlin is also very close to Java. It adds some niceties for sure, but they worked hard to make Kotlin very close to Java. Data classes are great, but you could easily turn a data class into a POJO by generating the getters/setters/equals/hashCode/toString. The lambdas are great, but you could easily turn that into a Java 8 lambda or a Java 6 anonymous function. You might lose some elegance in the conversion to Java, but there isn't a lot of ambiguity in the conversion.
Kotlin support is relatively easy for Google. It already existed via the normal Java support. Supporting Go and Dart means supporting an entirely parallel set of things.
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.
Java-level compile speed sounds amazing. My build system experience is with sbt, which is mostly slow on startup because it checks the versions of every library, every time. The rest of the slowness is from the Scala compiler. A fast Kotlin compile plus a fast command-line build resolution would be a killer combo.
> Standing on stage on Wednesday morning at Google I/O,
> Android PM Director Stephanie Saad Cuthbertson broke the
> news that Kotlin, which was first released in 2012, is now
> officially supported as a “first class” language for
> Android...
> developers whooped freely when told that they no longer had
> to worry that Kotlin fever was just a phase, to be
> abandoned like dozens of other cult favorites before it.
Nothing that google says about Kotlin could possibly mean that it's not a phase, to be abandoned like other cult favorites before it. Is Kotlin more official than Wave? Reader? Fiber? Loon? Boston Dynamics? Picasa? Titan? Glass? Google+? Labs? Gears? Code Search? Health? Knol? Orkut? Answers? Deskbar? Page Creator? Sites?
Google has the right to stop supporting whatever they want, but there is a hard-to-measure cost in developer trust (and goodwill).
Nearly all the no defunct things you list were not central to Google's mission. Android is, the move to kotlin was not some Willy nilly experiment it was a strategic move.
you make a good point, but I would argue that the existence of java means that there is absolutely no more necessity for kotlin, per se, than anything on the list. having it is great insurance for google against oracle, but it shouldn't give any assurance to developers.
There is definitely pressure from the community to use something other than java to develop Android apps. Add on the pressure from Apple with Swift/iOS it only makes sense that google would invest in ways to make app development easier and faster.
> There is definitely pressure from the community to use something other than java to develop Android apps.
People mainly want sane APIs and a retained-mode graphics stack that does not suck. Instead, we got lipstick on our pig (and even here, Google has never been the driving force, but merely reacted to the community).
You make it sound like Google is the only company to EOL underperforming products and services. How many products and services has Apple or Microsoft abandoned or shut down during their span? I'm guessing that list is very long.
They have the right to EOL what they want; but OP is still right to warn about it based on Google's history of EOLing stuff that has been liked by the community.
> How many products and services has Apple or Microsoft abandoned or shut down during their span?
Microsoft is the best example for commitment to API compatibility over decades, i.e. the polar opposite of Google.
The only way for Google to shut down Kotlin is to shut down Android.
It's really convenient for you that you only mentioned products that Google shut down and skipped the many products that Google still supports and constantly improving thru this day.
Luckily, Kotlin isn’t actually a Google product, but a product of JetBrains, which is independent. If Google drops support, Kotlin will continue existing.
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.
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.
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.
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.
I think the claim there is more like "you can already use the huge amount libraries/your existing code with Java and, with care, you can make your Scala code work the other way" than "interop is seamless back and forth."
Scala was around for a long time, perhaps if I could look at it with fresh eyes now I would consider it, but somehow I always had a feeling that Scala isn't for me. And now as Kotlin gaining momentum I'd rather stick with Kotlin.
I want first class IDE support and straightforwardness in my workhorse languages. For hobby languages I'd rather play with something like Red or Perl 6.
Well there are still problems there too. Try making a default interface method in Kotlin or invoke MethodHandle's invoke with a specific return type sans casting in Kotlin.
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 ]
Also, it's not hard to package all the stuff a language needs and put it into an APK. It's just messy and there are a lot of "edge cases" and things to work out (like the problem of interacting with the Platform, you'd need to call into a "Java" interface from your language, you'd need to run your app inside ART/Dalvik, maybe fork - https://stackoverflow.com/questions/39006044/repeatedly-fork... ).
And so if you spend half a year just getting something to run, and on the next Android version Google makes a change, and bamm, you might get left in the cold, because security or whatever.
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.
Google employees can destroy any post on reddit. Jetbrains copied that model. Anything about Jetbrains will have tons of artificial posts at the top, their crew upvoting it.
It's useless this sort of thing is killing social media completely.
WTF is kotlin and why would anyone in their right minds use a language from a text editor company. Beats me.
It's a language created by Jetbrains and they have all their employees heavily brigade promote stuff about Jetbrains on social media.
They also probably have an enormous team manipulating Reddit and hackernews votes (perhaps they run a internal email for everyone to vote and comment).
Kotlin is an unneeded solution to an inexistent problem. A language in no way comparable to Scala or Java. If you adopt it in your project you'll be in deep shit a couple years from now.
By the way, prepare for downvotes. This is a throwaway account. Jetbrains has all their employees and maybe even external marketing firms in these promotional posts. Especially on Reddit /r/programming my goodness they are obnoxious with their downvote brigades.
ReactNative isn’t exactly native, and the patent situation isn’t ideal either.
Kotlin is a language that is like a "better Java", just like C# is a better Java.
It happens to provide extension methods, it allows easy creation of domain specific languages, it fixes the Billion Dollar Mistake (no more problems with null!), etc. It’s basically Java, without all the boilerplate, and a lot more modern.
Which means any Android dev can easily use it, and be more productive, and create less bugs.
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
I noticed last week or so that Apache Kafka deprecated large amount of Scala API and put new Java API in its place. This can't be good for languages which already generate so much news but so little software.
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 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.
Google already tried compiling Java source code directly to Dalvik bytecode (the "Jack" compiler) but they recently abandoned that approach in favour of improving the regular Java-bytecode-based toolchain. Perhaps because of the new focus on Kotlin?
The Android toolchain used to be horrendously slow but has gotten a lot better since they switched from Eclipse and Ant to IntelliJ and Gradle – assuming you have enough RAM to dedicate a few GB to the persistent Gradle process. It now has incremental compilation (of Kotlin and Java), incremental dexing (i.e. converting the compiled Java bytecode to Dalvik bytecode) and incremental reloading ("Instant Run"). And the emulator can run the x86 version of Android nowadays, so it's no longer slowed down by emulating ARM. It's pretty nice.
When I see quotes like "Oh my God this is awesome" my sensors go to red flag mode full-time.
Devs are people like everybody else and can be hyped.
Let's give it time. Not sure what's the big fuss about. Yes I've read about GUI toolkits that reduce the development time. This still doesn't mean much IMO. The business owners will simply become more greedy and will demand more work for less money.
> 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...
;)
reply