Kotlin M13 is out!

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:

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:

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:

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:

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

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

  • 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!

About Andrey Breslav

Andrey is the lead language designer of Kotlin at JetBrains.
This entry was posted in Releases. Bookmark the permalink.

70 Responses to Kotlin M13 is out!

  1. cypressious says:

    Great news! How is incremental Gradle compilation coming along?

  2. Ivan Nikitin says:

    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:

      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”
      }

      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:

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

  4. Brian says:

    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)

  5. Mohammad Shamsi says:

    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:

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

    • Oliver Weiler says:

      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. 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

  7. Takuya Miyamoto says:

    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:

      Which version of Kotlin plugin have you tried to install?

      • Takuya Miyamoto says:

        0.13.1513.idea141.19

        I’ve tried to upgrade from old one.

        • Natalia Ukhorskaya says:

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

          • Mykola says:

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

          • Takuya Miyamoto says:

            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:

      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:

        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:

          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:

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

          • Pawel Byszewski says:

            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:

    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:

      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:

      Your code isn’t correct.

      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:

    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 ?

  10. Dmitry says:

    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:

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

    • Roman Belov says:

      Now you can write just:

  12. Ion says:

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

  13. nico says:

    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

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

      • nico says:

        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.

  14. Rob Fletcher says:

    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:

    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:

    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:

    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.

  18. Sergey says:

    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.

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

Comments are closed.