Blog Blog
Home
Home/Kotlin/Kotlin M13 is out!

Kotlin M13 is out!

Posted on by Andrey Breslav

It’s been a long summer, and we have a lot to tell you about Kotlin M13 (details below):

  • Compiler daemon for faster compilation;
  • lateinit properties to support dependency injection and other frameworks;
  • sealed classes for expressing closed hierarchies;
  • Specifying and checking annotation targets;
  • Java get/set pairs are now seen as properties in Kotlin;
  • Better type safety for Java interop: taking @NotNull annotations into account (see this blog post);
  • Modifiers and annotations have been separated syntactically (see this blog post);
  • Fully functional reflection on classes, functions and properties;
  • Access to internal is now checked outside of a module (details below);
  • New .class file layout for top-level functions and properties;
  • and more (see below)

Language changes

We are wrapping up with the language and making necessary changes to finalize the syntax as well as adding small things that are missing for critical use-cases. Some of the changes are breaking, and as usual we do our best to help you migrate.

Note that the 1.0 release which we’re working towards right now will be focused on the JVM support. The JavaScript backend will be included, but it will be considered an experimental feature. Because of that, there are few changes affecting JavaScript in this release. We plan to resume work on JS after the 1.0 release is out.

Late-init properties

One of the biggest issues when using Kotlin with frameworks that inject values into Java fields (i.e. Dependency Injection, Mocking, Serialization and other frameworks) used to be the inability to have a property of a non-null type that is not initialized in constructor.

Now, we introduce lateinit properties:

class Example {
    @Inject
    lateinit val foo: Foo
    @Inject
    lateinit var bar: Bar
}

Both foo and bar have no initializers, but at the same time declare a non-null type. If we try to read them before they are initialized, an exception will be thrown, but as soon as they are initialized by a DI framework (Guice, Dagger or Spring, for example), they can be read as normal properties.

Such properties can also be used for other use cases (such as JUnit setUp initialization). Note that val‘s can be marked lateinit as well as var‘s. Unlike vars, they can not be assigned freely in the code, but a framework can inject values into them without obstacles, because the underlying JVM fields are not marked as final.

See more in the language docs.

Sealed classes

Many people ask if Kotlin supports Algebraic Data Types (ADTs). The answer has always been: “Yes, ADTs can be expressed as classes in Kotlin, and when is practically as good as pattern matching”. Now we have added a bit more type-safety to it: with sealed classes we can make sure that all cases are enumerated in when:

package pets

import pets.Pet.*

sealed class Pet(val name: String) {
    class Dog(name: String): Pet(name)
    class Cat(name: String): Pet(name)
}

fun Pet.saySomething(): String {
    return when (this) {
        is Dog -> "woof"
        is Cat -> "meow"
    }
}

Note that else is not required in the example above: since Pet is a sealed class, the compiler knows that it has no subclasses other than Dog and Cat. So we can be sure that all cases have been checked and else is not needed. Incidentally, if you forget to cover some cases, the compiler will report an error and remind you to do it, or resort to else.

For now only classes nested into the sealed class can extend it, but we will later relax this restriction and allow subclasses in the same source file.

For more details see the docs.

Annotations require “@”

Modifiers and annotations have been separated syntactically (see this blog post) in M13. We now require a @ for annotations, and all annotation classes are supposed to be named starting with a capital letter (which brings better uniformity with Java).

Thus, library annotations such as @Throws, or @Volatile are renamed. We also renamed @platformName to @JvmName and @platformStatic to @JvmStatic.

Some former annotations have become modifiers:

  • data
  • inline-related
    • inline
    • noinline
    • crossiniline — instead of former @inlineOption(ONLY_LOCAL_RETURNS)
  • tailrec — instead of former @tailRecursive
  • external — instead of former @native

This change is transparent for most users since annotations that haven’t changed their names looked like modifiers before.

The old syntax and classes are deprecated.

The Code Cleanup IDE action will help you migrate your code.

Annotation targets and other options

Kotlin now supports the following annotation options (expressed as annotations on annotation classes):

  • @Retention – who can see this annotation: RUNTIME (default), BINARY (.class file only) or SOURCE;
  • @Target – where the annotation is applicable;
  • @MustBeDocumented – a marker that says that this annotation is a part of the API of the annotated element, and must be displayed in the generated documentation;
  • @Repeatable – a marker that says that this annotation may be used multiple times on the same element.

See more in the docs.

Additionally, we can now specify an optional target for annotations at use sites:

class Example(
    @field:MyFieldAnnotation(...)
    val foo: Foo
)

NOTE: this is a breaking change. Before M13 when we annotated parameters of primary constructors, annotations were written both on parameters and fields they are stored in. Now they are only written on one of the following (the first applicable): parameter, property, field. I.e. if the annotation is applicable to both field and parameter, it will only be written on the parameter now. This presents some issues when using Jackson, but there is an easy workaround: use the special Jackson module for Kotlin. And the old way didn’t have one.

Find more information in the docs.

Visibilities

We have revisited our access modifier/visibility model. From now on:

  • private on the top level (outside any class) means “visible only inside this source file”;
  • we do not require explicit return types for public declarations any more;
  • the default visibility (no modifier) is changed from internal to public,
  • we finally enabled the checks that reject usages of internal declarations outside a module.

This may seem controversial that we chose public as default visibility. Kotlin being a type-safe language, choosing the safest option, private, by default may seem more logical. And we totally realize there are valid arguments in favour of this default. But Kotlin is also a pragmatic language. I’ll try to explain briefly why we believe public is the right default.

In real Java code bases (where public/private decisions are taken explicitly), public occurs a lot more often than private (2.5 to 5 times more often in the code bases that we examined, including Kotlin compiler and IntelliJ IDEA). This means that we’d make people write public all over the place to implement their designs, that would make Kotlin a lot more ceremonial, and we’d lose some of the precious ground won from Java in terms of brevity. In our experience explicit public breaks the flow of many DSLs and very often — of primary constructors. So we decided to use it by default to keep our code clean.

NOTE: internal remains supported, but now you need to specify it explicitly.

Miscellaneous changes

  • Support for overloaded callable references: you can now use ::foo even if foo is overloaded, but the right signature can be chosen based on the context;
  • Unambiguous super can be used without angle brackets;
  • Strict nullability checks for type parameters;
  • Functions with no default parameters are preferred in overload resolution (good for API evolution);
  • @HiddenDeclaration annotation introduced to hide declarations from clients while keeping them in the binaries (also for smoother API evolution).

Java interop changes

Java get/set pairs are now seen as properties

People have been asking for this feature for a long time, and it took us a while to figure it out. Now when we use Java classes that define properties by convention (e.g. getFoo() and maybe setFoo()), Kotlin automatically defines corresponding extension properties:

// Java:

class JBean {
    public Foo getFoo() { return ...; }
    public void setFoo(Foo foo) { ... }
}

// Kotlin

fun demo(bean: JBean) {
    println(bean.foo) // 'foo' is automatically defined
}

Access to such properties is optimized so that bean.foo compiles to bean.getFoo() without any intermediate calls.

New layout of .class files for top-level declarations

A few months ago we announced this change and now it’s done:

  • By default, each Kotlin source file (e.g. myFile.kt) produces a class file with the same name, capitalized and suffixed with “Kt”: MyFileKt;
  • Top-level functions and properties defined in that file are accessible in Java through this class name (instead of the problematic FooPackage);
  • Consequently, two files in the same package can not have the same name (or the class files would clash);
  • You can specify a @file:JvmName("CustomName") annotation on a source file to change the name of the class;
  • Many files can share the same JVM name if they are additionally marked with @file:JvmMultifileClass annotation.

To make this change work, we had to introduce a new resource file that is required to compile Kotlin code against Kotlin binaries. Its name is META-INF/<module_name>.kotlin_module. Make sure these .kotlin_module files are not stripped by your packaging process. Also, make sure that module names do not clash in your project:

  • in Maven we use groupId and artifactId for module names, but you can say

<configuration>
    <moduleName>com.example.mymodule</moduleName>
</configuration>

  • in Gradle it’s project name + build task name, to customize:

compileKotlin {
    kotlinOptions.moduleName = "com.example.mymodule"    
}

  • in Ant and command line you should specify module names explicitly:
    • <kotlinc modulename="com.example.mymodule"/>
    • $ kotlinc-jvm -module-name com.example.mymodule

More information can be found here.

Null-safety in Java interop

We first announced this a while ago. Now we can use @NotNull and @Nullable in Java and Kotlin recognizes them so that misuse results in compilation errors rather than warnings.

As a consequence, using Java collections has become a lot safer: we can not put a null into an ArrayList<String> any more.

Platform types are kept in place, because annotations are often missing and sometimes wrong (violate inheritance rules, for example), so by default no static null-checks are imposed onto Java code.

External annotations are not used either, so we have spared you quite some build configuration.

Libraries

Kotlin libraries are also being actively developed. M13 brings fully functional reflection library: we can now introspect classes, their members, parameters etc. A separate blog post about this is coming.

The standard library has got many convenient additions including

  • + and - for sets and other collections;
  • improved delegates for properties.

More on this is a separate post too.

Tools

Compiler daemon. We announced support for Gradle Daemon a while ago and your feedback has been positive: compilation times seem to go down up to a factor of three. We keep working on compilation performance, and since M13 a daemon similar to Gradle’s is used in IntelliJ IDEA as well. This feature is marked “experimental” for now, so you need to tick a box in the Preferences dialog to switch it on:

Build, execution, deployment -> Compiler -> Kotlin compiler -> Keep compiler process alive between invocations (experimental)

Incremental compilation is another direction we have taken to improve Kotlin compilation times. M13 brings:

  • incremental compilation for inline functions: now if you change a body of an inline function, only classes that use it are recompiled;
  • changes to private members do not cause recompilation of other files.

IDE

The IDE experience has been improved too. For the sake of brevity we highlight only those features that are not easily discovered:

  • The IDE suggests name and type of parameters when typing:
    (Hint: hover mouse over image to start animation)

  • As mentioned above we’ve introduced synthetic properties instead of Java get/set pairs. But one can be still Java-minded and start to type “get” instead of property name. So completion suggests properties in such cases.

  • If you want to iterate over some collection just type its name and special intention action can convert it to a for loop:

  • Another intention action can add/remove indices to for loops:

  • Named arguments can drastically improve code readability. Kotlin IDE now provides action to switch arguments to named form and back:

  • Highlighting of unused imports is also supported now. And it’s now possible to switch on the option to optimize imports on the fly:

  • Debugger now supports Smart Step Into (⇧F7) for lambda expressions as well as highlighting of lambda expression which is currently being executed:

    NB: This functionality is available only in IntelliJ IDEA 15 EAP (from ver. 142.4465) and only for non-inline lambda expressions.

  • Debugger provides Step Over (F8) and Step Out (⇧F8) for inline functions along with availability of all local variables from functions inside Evaluate Expressions

  • Java2Kotlin converter now supports Java 8 Method References
  • Refactoring support for Pull Members Up/Down
  • Executable items such as main(..), tests, etc are marked with gutter icons which can show popup menu with run configurations (for IntelliJ IDEA 15 EAP only)

Installation

In IntelliJ IDEA 14.1 simply update the plugin through plugin manager (as usual).

In IntelliJ IDEA 15 EAP has Kotlin M12 bundled with it, so to update to M13 you need to

  • Download the plugin zip
  • Open Preferences -> Plugins and choose Install plugin from disk… to install it
  • Restart the IDE

We will make update process smoother in the next EAPs of IntelliJ IDEA.

As usual, the standalone compiler can be found here.

Have a nice Kotlin!

Comments below can no longer be edited.

70 Responses to Kotlin M13 is out!

  1. cypressious says:

    September 16, 2015

    Great news! How is incremental Gradle compilation coming along?

  2. Ivan Nikitin says:

    September 16, 2015

    Andrey, thanks a lot for the meaningful update! Though I noticed that after upgrading my gradle project, the compiler says Kotlin: Unresolved reference: arrayOf everywhere I used this function. Did you make unmentioned breaking change? What’s the correct way to build array of strings now?

    • Ivan Nikitin says:

      September 16, 2015

      Figured it out. After upgrade, kotlin version variable was updated incorrectly.
      build.gradle:
      ext {
      kotlin_version = ‘0.12.613’ // New
      springBootVersion = “1.3.0.M4”
      }

      turned to 

ext.kotlin_version = '0.13.1513'
ext {
    kotlin_version = '0.12.613'  // New
    springBootVersion = "1.3.0.M4"
}

      After that I got two version of kotlin-runtime.jar in my project (F4). I removed both libraries using IntelliJ UI, refreshed the Gradle project and compilation started working again as expected.

  3. Mounir Boudraa says:

    September 16, 2015

    What about Anko. Will it be updated to kotlin m13 ?

    • Yan Zhulanow says:

      September 17, 2015

      I am going to release the M13-compatible version today. Please stay tuned!

      • Mounir Boudraa says:

        September 18, 2015

        Thanks. Well received 😉

  4. Brian says:

    September 16, 2015

    Thanks for the update. I’m now getting the following error when gradle hits compileDebugKotlin
    Any idea what’s going on?

    Error:java.lang.IllegalArgumentException: Don’t know how to render diagnostic of type SYNTHETIC_UNRESOLVED_WIDGET_TYPE
    at org.jetbrains.kotlin.diagnostics.rendering.DefaultErrorMessages.render(DefaultErrorMessages.java:82)

    • Omar Miatello says:

      September 17, 2015

      I have the same problem with the custom view (written in Kotlin). If you try to preview a layout that contains the custom view probably you read:

      The following classes could not be found:
      – com.example.ui.CustomLayout (Fix Build Path, Create Class)
      Tip: Try to build the project.

      Now I’m trying to figure out how to fix it
      NOTE: with M12 it’s all fine.

      • Omar Miatello says:

        September 17, 2015

        My temporary solution is:

        val customLayout = findViewById(R.id.customLayout) as CustomLayout

        instead of synthetic property

    • Yan Zhulanow says:

      September 17, 2015

      This is a bug indeed. A fix will be available shortly.
      Thank you!

  5. Mohammad Shamsi says:

    September 17, 2015

    Great job. Thanks for the updates. I really like the updates in M13.

    Do you have any plan to support collection literals ?
    e.g. in Groovy:
    – [] for list ( val list = [1, 2, 3] )
    – [:] for map ( val map = [“key” : “value, …] )

    Also it would be nice to have a simpler approach to define regular expressions. The Java style needs so many charterer escaping which makes it not quite readable.

    • Christian says:

      September 17, 2015

      You can simply use multi-line strings like """\d+""" to avoid double escaping in regex. See example.

    • Oliver Weiler says:

      September 17, 2015

      There actually is a simple approach to define regular expressions (albeit undocumented) – use a raw string:

      “/restnames/name\.groovy\?name=$1”
      “””/restnames/name.groovy\?name=$1″””

  6. Artem Zinnatullin says:

    September 17, 2015

    We have problems with M13 + ProGuard (minifyEnable true in Android project).

    Unfortunately, I can not find anything useful in the logs and I can not share sources, but I hope, you will be able to reproduce easily.


    Exception while processing task
    java.lang.StringIndexOutOfBoundsException: String index out of range: 37
    at java.lang.String.charAt(String.java:646)
    at proguard.classfile.util.DescriptorClassEnumeration.nextFluff(DescriptorClassEnumeration.java:173)
    at proguard.classfile.util.DescriptorClassEnumeration.classCount(DescriptorClassEnumeration.java:69)
    at proguard.classfile.util.ClassReferenceInitializer.findReferencedClasses(ClassReferenceInitializer.java:500)
    at proguard.classfile.util.ClassReferenceInitializer.visitSignatureAttribute(ClassReferenceInitializer.java:340)
    at proguard.classfile.util.SimplifiedVisitor.visitSignatureAttribute(SimplifiedVisitor.java:339)
    at proguard.classfile.util.SimplifiedVisitor.visitSignatureAttribute(SimplifiedVisitor.java:351)
    at proguard.classfile.attribute.SignatureAttribute.accept(SignatureAttribute.java:109)
    at proguard.classfile.ProgramMethod.attributesAccept(ProgramMethod.java:81)
    at proguard.classfile.util.ClassReferenceInitializer.visitProgramMethod(ClassReferenceInitializer.java:139)
    at proguard.classfile.ProgramMethod.accept(ProgramMethod.java:73)
    at proguard.classfile.ProgramClass.methodsAccept(ProgramClass.java:516)
    at proguard.classfile.util.ClassReferenceInitializer.visitProgramClass(ClassReferenceInitializer.java:104)
    at proguard.classfile.ProgramClass.accept(ProgramClass.java:358)
    at proguard.classfile.ClassPool.classesAccept(ClassPool.java:124)
    at proguard.Initializer.execute(Initializer.java:146)
    at proguard.ProGuard.initialize(ProGuard.java:233)
    at proguard.ProGuard.execute(ProGuard.java:98)
    at proguard.gradle.ProGuardTask.proguard(ProGuardTask.java:1074)
    at com.android.build.gradle.tasks.AndroidProGuardTask.doMinification(AndroidProGuardTask.java:139)
    at com.android.build.gradle.tasks.AndroidProGuardTask$1.run(AndroidProGuardTask.java:115)
    at com.android.builder.tasks.Job.runTask(Job.java:48)
    at com.android.build.gradle.tasks.SimpleWorkQueue$EmptyThreadContext.runTask(SimpleWorkQueue.java:41)
    at com.android.builder.tasks.WorkQueue.run(WorkQueue.java:227)
    at java.lang.Thread.run(Thread.java:745)
    :proguardDebug

    • Vladimir Mironov says:

      September 17, 2015

      And here is a string that causes the exception – <![CDATA[(TA;I)TA;]]>

    • Loong_T says:

      September 17, 2015

      I have encountered this problem as well.

    • Eugene Biletskiy says:

      September 17, 2015

      Do you use Kotlin for apps in production?

      • Artem Zinnatullin says:

        September 17, 2015

        It does not matter, problem needs to be fixed anyway.
        And yes, why not? 🙂

    • Martynas says:

      September 17, 2015

      Same here. Although in my case it was because of multidex, when performing task application:shrinkDebugMultiDexComponents`

    • Eugene Krivenja says:

      September 17, 2015

      Same issue

    • Alexander Udalov says:

      September 17, 2015

      This is being worked on and the fix will be released soon. Here’s the issue: https://youtrack.jetbrains.com/issue/KT-9184

      • Alexander Udalov says:

        September 21, 2015

        Update: the problem has been fixed and the new build 0.13.1514 is now released, please try it out.

        • Karol says:

          September 22, 2015

          Can confirm, worked for me.

  7. Takuya Miyamoto says:

    September 17, 2015

    In Android Studio 1.3.2, I got the following error in installing the plugin.

    org.jetbrains.kotlin.idea.compiler.configuration.KotlinCompilerConfigurableTab has unsatisfied dependency: class com.intellij.openapi.options.ConfigurableEP among unsatisfiable dependencies: [[class com.intellij.openapi.options.ConfigurableEP]] where com.intellij.util.pico.DefaultPicoContainer@7da3b172 was the leaf container being asked for dependencies.
    org.picocontainer.defaults.UnsatisfiableDependenciesException: org.jetbrains.kotlin.idea.compiler.configuration.KotlinCompilerConfigurableTab has unsatisfied dependency: class com.intellij.openapi.options.ConfigurableEP among unsatisfiable dependencies: [[class com.intellij.openapi.options.ConfigurableEP]] where com.intellij.util.pico.DefaultPicoContainer@7da3b172 was the leaf container being asked for dependencies.
    at com.intellij.util.pico.ConstructorInjectionComponentAdapter.getGreediestSatisfiableConstructor(ConstructorInjectionComponentAdapter.java:113)
    at org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1.run(ConstructorInjectionComponentAdapter.java:210)
    at org.picocontainer.defaults.ThreadLocalCyclicDependencyGuard.observe(ThreadLocalCyclicDependencyGuard.java:53)
    at org.picocontainer.defaults.ConstructorInjectionComponentAdapter.getComponentInstance(ConstructorInjectionComponentAdapter.java:248)
    at com.intellij.util.pico.ConstructorInjectionComponentAdapter.getComponentInstance(ConstructorInjectionComponentAdapter.java:58)
    at com.intellij.openapi.extensions.AbstractExtensionPointBean.instantiate(AbstractExtensionPointBean.java:75)
    at com.intellij.openapi.options.ConfigurableEP$ClassProducer.createElement(ConfigurableEP.java:241)
    at com.intellij.openapi.options.ConfigurableEP.createConfigurable(ConfigurableEP.java:167)
    at com.intellij.openapi.options.ex.ConfigurableWrapper.getConfigurable(ConfigurableWrapper.java:111)
    at com.intellij.openapi.options.ex.ConfigurableWrapper.cast(ConfigurableWrapper.java:94)
    at com.intellij.openapi.options.ex.ConfigurableCardPanel.prepare(ConfigurableCardPanel.java:35)
    at com.intellij.openapi.options.ex.ConfigurableCardPanel.prepare(ConfigurableCardPanel.java:32)
    at com.intellij.ui.CardLayoutPanel$1.run(CardLayoutPanel.java:114)
    at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:400)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jetbrains.ide.PooledThreadExecutor$1$1.run(PooledThreadExecutor.java:56)

    org.picocontainer.defaults.UnsatisfiableDependenciesException: org.jetbrains.kotlin.idea.compiler.configuration.KotlinCompilerConfigurableTab has unsatisfied dependency: class com.intellij.openapi.options.ConfigurableEP among unsatisfiable dependencies: [[class com.intellij.openapi.options.ConfigurableEP]] where com.intellij.util.pico.DefaultPicoContainer@7da3b172 was the leaf container being asked for dependencies.
    at com.intellij.util.pico.ConstructorInjectionComponentAdapter.getGreediestSatisfiableConstructor(ConstructorInjectionComponentAdapter.java:113)
    at org.picocontainer.defaults.ConstructorInjectionComponentAdapter$1.run(ConstructorInjectionComponentAdapter.java:210)
    at org.picocontainer.defaults.ThreadLocalCyclicDependencyGuard.observe(ThreadLocalCyclicDependencyGuard.java:53)
    at org.picocontainer.defaults.ConstructorInjectionComponentAdapter.getComponentInstance(ConstructorInjectionComponentAdapter.java:248)
    at com.intellij.util.pico.ConstructorInjectionComponentAdapter.getComponentInstance(ConstructorInjectionComponentAdapter.java:58)
    at com.intellij.openapi.extensions.AbstractExtensionPointBean.instantiate(AbstractExtensionPointBean.java:75)
    at com.intellij.openapi.options.ConfigurableEP$ClassProducer.createElement(ConfigurableEP.java:241)
    at com.intellij.openapi.options.ConfigurableEP.createConfigurable(ConfigurableEP.java:167)
    at com.intellij.openapi.options.ex.ConfigurableWrapper.getConfigurable(ConfigurableWrapper.java:111)
    at com.intellij.openapi.options.ex.ConfigurableWrapper.createComponent(ConfigurableWrapper.java:162)
    at com.intellij.openapi.options.ex.ConfigurableCardPanel$1.compute(ConfigurableCardPanel.java:54)
    at com.intellij.openapi.options.ex.ConfigurableCardPanel$1.compute(ConfigurableCardPanel.java:51)
    at com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(ApplicationImpl.java:884)
    at com.intellij.openapi.options.ex.ConfigurableCardPanel.create(ConfigurableCardPanel.java:51)
    at com.intellij.openapi.options.newEditor.ConfigurableEditor$1.create(ConfigurableEditor.java:64)
    at com.intellij.openapi.options.newEditor.ConfigurableEditor$1.create(ConfigurableEditor.java:61)
    at com.intellij.ui.CardLayoutPanel.createValue(CardLayoutPanel.java:73)
    at com.intellij.ui.CardLayoutPanel.select(CardLayoutPanel.java:101)
    at com.intellij.ui.CardLayoutPanel.access$000(CardLayoutPanel.java:35)
    at com.intellij.ui.CardLayoutPanel$1$1.run(CardLayoutPanel.java:118)
    at com.intellij.openapi.application.impl.LaterInvocator$FlushQueue.run(LaterInvocator.java:332)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
    at java.awt.EventQueue.access$500(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:709)
    at java.awt.EventQueue$3.run(EventQueue.java:703)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
    at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:734)
    at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:569)
    at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:382)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:109)
    at java.awt.WaitDispatchSupport$2.run(WaitDispatchSupport.java:184)
    at java.awt.WaitDispatchSupport$4.run(WaitDispatchSupport.java:229)
    at java.awt.WaitDispatchSupport$4.run(WaitDispatchSupport.java:227)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.awt.WaitDispatchSupport.enter(WaitDispatchSupport.java:227)
    at java.awt.Dialog.show(Dialog.java:1084)
    at com.intellij.openapi.ui.impl.DialogWrapperPeerImpl$MyDialog.show(DialogWrapperPeerImpl.java:778)
    at com.intellij.openapi.ui.impl.DialogWrapperPeerImpl.show(DialogWrapperPeerImpl.java:465)
    at com.intellij.openapi.ui.DialogWrapper.invokeShow(DialogWrapper.java:1614)
    at com.intellij.openapi.ui.DialogWrapper.show(DialogWrapper.java:1571)
    at com.intellij.ide.actions.ShowSettingsUtilImpl.showSettingsDialog(ShowSettingsUtilImpl.java:114)
    at com.intellij.ide.actions.ShowSettingsAction.actionPerformed(ShowSettingsAction.java:65)
    at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher$3.performAction(IdeKeyEventDispatcher.java:593)
    at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.processAction(IdeKeyEventDispatcher.java:644)
    at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.inInitState(IdeKeyEventDispatcher.java:483)
    at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.dispatchKeyEvent(IdeKeyEventDispatcher.java:213)
    at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:538)
    at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:382)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

    • Natalia Ukhorskaya says:

      September 17, 2015

      Which version of Kotlin plugin have you tried to install?

      • Takuya Miyamoto says:

        September 17, 2015

        0.13.1513.idea141.19

        I’ve tried to upgrade from old one.

        • Natalia Ukhorskaya says:

          September 18, 2015

          Was the plugin installed? This exception can occur when you open Settings menu, but shouldn’t disturb you writing code in Kotlin.

          • Mykola says:

            September 18, 2015

            A saw this error too when try to open Settings -> Kotlin Compiler tab

          • Takuya Miyamoto says:

            September 19, 2015

            It was installed but I want to try compiler daemon feature and I don’t find the ‘Kotlin compiler’ item which seems to be caused by this problem.

    • Pawel Byszewski says:

      September 18, 2015

      When I try to install plugin on Android Studio 1.4 Beta 3 it shows me “Plugin Kotlin is incompatible with this instalation” 🙁

      • Natalia Ukhorskaya says:

        September 18, 2015

        Have you tried to install 0.13.1513.Idea141.19? Not 0.13.1513.Idea142.11?
        Android Studio 1.4 Beta 3 should propose you to update Kotlin Plugin to 0.13.1513.Idea141.19, does it? If not, you can download it from https://plugins.jetbrains.com/plugin/6954?pr=idea.

        • Pawel Byszewski says:

          September 18, 2015

          Thanks for response:) I have tried and now there is an error after restart Android Studio, now kotlin plugin must be disable to event start android studio.
          stacktrace: http://pastebin.com/eGfzjYqj

          my config:
          kotlin plugin: 0.13.1513.Idea141.19
          android studio: 1.4 beta 3

          • Natalia Ukhorskaya says:

            September 18, 2015

            Seems that your installation was corrupted somehow. Could you try to uninstall plugin -> restart Android Studio -> install plugin one more time?

          • Pawel Byszewski says:

            September 19, 2015

            Natalia this is almost exactly what I have done:) moreover I update Android Studio to beta 4 and now I enjoy m13 in my app 🙂

  8. Tyler Prete says:

    September 17, 2015

    Was there a regression on local reflection?

    This was working for me in M12:


    fun main(args: Array) {
    fun thing(i: Int) = i + 1
    (1..5).map { ::thing }.forEach { println(it) }
    }

    but now gives:
    Exception in thread “main” kotlin.reflect.KotlinReflectionInternalError: Introspecting local functions, lambdas and function expressions is not yet fully supported in Kotlin reflection

    And I do have kotlin-reflection.jar in my classpath.

    • Alexander Udalov says:

      September 17, 2015

      UPD: see Jayson’s comment below for the correct explanation.

      In M12, “toString” was not implemented for function references, so in your example you would get a bunch of useless “_DefaultPackage$1$1f2b02fb$main$2$1@6001654”-like strings printed out. In M13, there’s a sensible “toString” for function references but its implementation relies on Kotlin reflection which is not complete for local functions, so an exception is thrown. I think instead of throwing the exception we could return something simple like “local function foo”, until the full reflection support for local functions is there. Thanks for noticing!

    • Jayson Minard says:

      September 17, 2015

      Your code isn’t correct.

      fun main(args: Array) {
  fun thing(i: Int) = i + 1
  (1..5).map(::thing).forEach { println(it) }
}

      otherwise you are mapping it from a number to a function reference, not a number to the result of the call to the function. Not sure my change is correct either, but it would be closer to that () instead of {}

  9. Salomon BRYS says:

    September 17, 2015

    Hi there,
    great work !

    Here are my thought about M13 :

    Late-init: I’m sorry to say that I think it’s a mistake. Not having the backing field of a val final means that reflection can not only initialize it but also MODIFY it. Meaning that all assumption that we and the compiler can do in the case of a val (for example, the fact that a non null class property will stay non null because a thread cannot change it) will not be valid anymore. That means that we now need to hope that Java reflection libraries will respect the kotlin contract : initialize once and not touch this anymore. Knowing what’s doable with Java reflection, I think late-init will be thoroughly abused. Most DI libraries support injection by method, I think this would ha been the way to go : for example, a lateinit properties exposes a setter than can be called by reflection but can only be called once.

    Sealed classes: Great work 🙂

    Annotations: I’m sad to see keyword-like annotations go, that was kind of badass. But I do understand why and agree with your choice. Still, it was fun while it lasted.

    Annotation targets: Great (much needed) work 😉

    Visibility: This is, by far, the most important change of M13. As I’ve stated in the forum, I agree with this change. However, I do very much regret the lack of communication of this change. I mean, this is very important, it cannot be automatically be migrated by the IDE so it requires a thorough review of our entire code base and it really changes the way we read and write kotlin code. I really regret that you didn’t at least write a blog post to warn us and I do believe that this would have deserved a thread on the forum to consult the community, or at least, take the pulse. Once again, I agree with the decision, but I think it’s to big of a change to consult or at least warn us.

    Miscellaneous changes, java interrop, Libraries, Tools and IDE: Very very great work 😉

    Although I do not agree with everything, thank you very much guys to keep up the good work and creating the best JVM language out there 😉

    Finally, there’s one think that I believe is missing before 1.0 : the ternary:
    val value = isInDB() ? db.findModel(key) : defaultValue
    This construct exists in every language I knwo except Kotlin, and I really miss it. Is it scheduled ?

    • Kirill Rakhman says:

      September 17, 2015

      Reflection can change final fields anyway.

      • Salomon BRYS says:

        September 17, 2015

        That’s very sad

        • Kirill Rakhman says:

          September 17, 2015

          It’s a security risk in some cases, but also useful in other cases. It’s how the JVM works.

    • Andrey Breslav says:

      September 17, 2015

      You are right about visibilities. I should have posted an announcement in advance. It has just slipped my mind/TODO list. Sorry.

      The ternary operator is not coming before 1.0, and I’m not sure whether it’s coming at all (and I know a few widely used languages that don’t have more that Kotlin has in this respect)

    • Rostislav says:

      September 17, 2015

      https://gist.github.com/naixx/9d94c1498c4d45ffda3a
      Here is a limited version of “ternary” operator 🙂

  10. Dmitry says:

    September 17, 2015

    Wow, “private == source only” is really great – somehow that’s what I was really missing, it seemed kinda misleading the way it was earlier – no way to hide, restrict something in single file.

    Other changes are really great too, thank you for great work, keep it up!

  11. Tommy Visic says:

    September 17, 2015

    Thanks for the update! Any hints on how the new property delegates work re: mapVar? E.g. wow does this code change? Thanks!

    val properties = hashMapOf<String, Any?>()
var name: String by Delegates.mapVar(properties)

    • Roman Belov says:

      September 18, 2015

      Now you can write just:

      import kotlin.properties.get
import kotlin.properties.set
...
val properties = hashMapOf<String, Any?>()
var name: String by properties

      • Tommy Visic says:

        September 18, 2015

        Ah I was missing the imports. Thanks much.

  12. Ion says:

    September 18, 2015

    Hello,
    What about libraries like kotlin-swing and kotlin-jdbc
    they are still M12

  13. nico says:

    September 18, 2015

    Was the M13 stdlib pulled from maven central? Things worked well yesterday but today you can see the metadata is there, but not the jar (clicking on download jar returns 404):

    http://mvnrepository.com/artifact/org.jetbrains.kotlin/kotlin-stdlib/0.13.1513

    • Andrey Breslav says:

      September 18, 2015

      Looks fine from here. Is it still missing for you?

      • nico says:

        September 18, 2015

        wget “http://central.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib/0.13.1513/kotlin-stdlib-0.13.1513.jar”
        –2015-09-18 21:25:44–
        http://central.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib/0.13.1513/kotlin-stdlib-0.13.1513.jar
        Resolving central.maven.org (central.maven.org)... 185.31.17.209
        Connecting to central.maven.org (central.maven.org)|185.31.17.209|:80... connected.
        HTTP request sent, awaiting response... 404 Not Found
        2015-09-18 21:25:44 ERROR 404: Not Found.

        • nico says:

          September 19, 2015

          works now

  14. Rob Fletcher says:

    September 18, 2015

    Great work. Some of the latest changes are very compelling.

    Is there an updated version of Spek forthcoming? My test classes will no longer compile with the new version of Kotlin.

  15. CountMath says:

    September 19, 2015

    Awesome update, but the biggest issue I am having with using Kotlin is figuring out how to have static final (a constant) that get inlined into the binary. I use these a lot in games and it is a memory concern to have all of these constants floating around in each instance of an object as well as a performance concern if they are not being inlined. I have yet to find a static constant variable in Kotlin. I can put a val in a file, but it get very messy that way. Do you think Kotlin will ever adopt a similar thing as Java has with its inlined static final primitives?

  16. Sven Jacobs says:

    September 19, 2015

    lateinit is awesome! Now injected fields via dependency injection can finally be vals and the syntax looks much nicer than @publicField @Inject …

    Great work! The language gets better and better!

  17. JayC says:

    September 22, 2015

    I think you should roll back the ‘public is the new default’ change. It is way less bug-prone for everyone when the defaults are private.

    • Andrey Breslav says:

      September 22, 2015

      Defaults were never private

    • Mykola says:

      September 22, 2015

      I disagree. In any case most of the methods in any projects are public. So why to force developers to write extra boilerplate

  18. Sergey says:

    September 28, 2015

    After upgrading to this new version all my MutableList instantiations became red in IDE, and all ways from withing the Internet on how to instantiate such properties do not work.

    So, how can I instantiate the following property now ? :
    public var serviceUrls: MutableList<ServiceURLKt?>? = ….

    Things like: = arrayListOf(ServiceURLKt()) , arrayOf(ServiceURLKt) and others do not work… All instantiations are red in IDE, though compilable…

    Kotlin version: 0.13.1415, IDE version : 141.1532.

    • Andrey Breslav says:

      September 28, 2015

      Looks like there’s an issue with your IDE/setup. Please try to invalidate IDE caches: File -> Invalidate Caches / Restart…

      • Sergey says:

        September 29, 2015

        Didn’t help, still “arrayListOf” red-colored… How can I send JetBrains diagnostic info to investigate the case ?

  19. IntelliJ IDEA 15 EAP und Kotlin M13 vereint - JAXenter says:

    September 29, 2015

    […] Last but not least wurden auch das Indexing, die Codevervollständigung und der Build-Tools-Support verbessert. Eine ausführliche Beschreibung der Änderungen findet sich in der Release-Mitteilung des 13. Meilensteins. […]

Latest Tweets

Related posts

Kotlin 1.4.0-RC: Debugging coroutines

We continue to highlight the upcoming changes in 1.4 release. In this blogpost, we want to describe a couple of important features related to coroutines: New functionality to conveniently debug coroutines The ability to define deep recursive functions These changes are already available for you to try in the 1.4.0-RC release! Let’s dive into details. Debugging coroutines Coroutines are great for asynchronous programming (but not only for that), and many people already use them or are starting to use them. When you write code with coroutines, however, trying to debug them can be a real pain.
Posted on by Svetlana Isakova

Kotlin 1.4.0-RC Released

We’re almost there! We're happy to unveil Kotlin 1.4.0-RC – the release candidate for the next major version of our programming language. Read on to learn about what has changed in Kotlin 1.4.0-RC, and make sure to try its new features before they are officially released with Kotlin 1.4.0. A special thanks to everyone who tried our milestone releases (1.4-M1, 1.4-M2, and 1.4-M3), shared their feedback, and helped us improve this version of Kotlin! This post highlights the new features and key improvements that are available in Kotlin 1.4.0-RC: Improved *.gradle.kts IDE support, with explicit
Posted on by Sebastian Aigner
Subscribe

Subscribe for updates