kapt, an Annotation Processing Tool for Kotlin, some time ago, and discussed its limitations. Now most of the limitations are going away with the updated version of
kapt that is available as a
0.1-SNAPSHOT preview. Continue reading
Kotlin is undergoing finalization, and as part of the process we are cleaning up: revising the language and its libraries. The biggest changes have been made in M12, but some more are coming. The point is to perform all the necessary breaking changes before we release 1.0, so that we can keep the language and libraries backwards-compatible after the release.
The trick is both we, ourselves, and you, our users, have quite a bit of code written in Kotlin already, and we don’t want all that code broken hopelessly on each update (some breakages are inevitable, unfortunately, but we are doing our best). The general scheme of making changes in a user-friendly way is “deprecate-release-remove”, for example:
- in M12 we deprecated quite a few language constructs and library classes/functions,
- then we released M12, so that whenever you use those to-be-removed language and library features, the compiler issues warnings,
- in the next milestone we will remove those deprecated things completely, so that the compiler will issue errors instead of warnings.
So, if you have any deprecation warnings in your code, now is just the right time to get rid of them: the next major update will make all that code red, and your build will break.
Getting rid of deprecation warnings
As mentioned above, there are two kinds of deprecation warnings: language deprecations and library deprecations. To get rid of them we provide several options.
Kotlin Eclipse Plugin 0.2.0
Today we are happy to present a new version of Kotlin plugin for Eclipse. This release includes the following features:
- Update to Kotlin M12
- Java to Kotlin converter
- Navigation to Kotlin sources from Java
- Kotlin syntax highlighting in Compare View
In the previous post we mentioned that the Quasar library now supports Kotlin, providing awesome support for fibers (lightweight threads), Go-like channels, Erlang-like actors, and other asynchronous tools.
Our friends from Parallel Universe have published a blog post that dives into details of using Quasar with Kotlin. Even in the unlikely case that multithreading doesn’t concern you much, Quasar/Kotlin integration is a great example of a “DSL” library written in Kotlin, it uses
- data classes
- top-level functions
- annotated expressions
- inline functions
to build a natural-looking and efficient API, and the blog post explains it very well.
We are happy to present Kotlin M12, bringing some rather important changes and new features:
- New syntax for annotations and enums
- More convenient semantics of function types
- Better smart casts
kapt for Java Annotation Processing support
- Multiple IDE features
- and more…
This post is largely outdated.
Please check out Better Annotation Processing: Supporting Stubs in kapt
As there have been many requests to support Java Annotation Processing, we are working on it, and first results are ready for preview. This is the call for early feedback. Continue reading
Last week we published a new version of Anko. While the main purpose of this library is creating layouts though a DSL, even the users of XML layouts can benefit from it. Today we are going to talk about such “ambivalent” features of Anko. Continue reading
Today we are glad to present the new version of Anko — a library which facilitates Android application development. We are happy to have received lots of feedback, and some of the changes in 0.6 were actually proposed by the community.
We released Kotlin Web Demo quite a while ago, it did a good job helping people try Kotlin right in the browser and share runnable code with each other. Now, a shiny new version is ready, it’s time to retire the old one.
Meet try.kotlinlang.org, as new incarnation of a web-based mini-IDE for Kotlin. Continue reading
Our battle for combining null-safety and Java interop has been a long one already:
- we started off treating all Java reference types as nullable, and it was too inconvenient;
- then we employed external annotations to specify nullability, created KAnnotator, but the whole thing was too fragile when versioning was concerned, and sometimes the users couldn’t do what they needed to (especially when it came to inheritance);
- in M9 we discarded the annotations (for the time being), and introduced platform types, now anything could be done, but we lost (some) type-safety;
- in M11 we started bringing the useful aspects of annotations back by issuing warnings where Java nullability constraints were violated.
Now, we are planning to make one more step and use annotations in combination with platform types to bring back as much type-safety as possible. Continue reading