Kotlin M13 is out!

Posted on September 16, 2015 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
}

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

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
)

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
}

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

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

</configuration>

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

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

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.

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.

View all posts by Andrey Breslav →

This entry was posted in Releases. Bookmark the permalink.

70 Responses to Kotlin M13 is out!

cypressious says:

September 16, 2015 at 8:01 pm

Great news! How is incremental Gradle compilation coming along?
Ivan Nikitin says:

September 16, 2015 at 8:10 pm

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 at 8:16 pm
  
  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" }
  
  1
  2
  3
  4
  5
  6
  7
  8
  
  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.
Mounir Boudraa says:

September 16, 2015 at 9:29 pm

What about Anko. Will it be updated to kotlin m13 ?
- Yan Zhulanow says:
  
  September 17, 2015 at 1:36 pm
  
  I am going to release the M13-compatible version today. Please stay tuned!
  - Mounir Boudraa says:
    
    September 18, 2015 at 12:33 pm
    
    Thanks. Well received 😉
Brian says:

September 16, 2015 at 10:05 pm

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 at 1:05 pm
  
  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 at 2:11 pm
    
    My temporary solution is:
    
    val customLayout = findViewById(R.id.customLayout) as CustomLayout
    
    instead of synthetic property
- Yan Zhulanow says:
  
  September 17, 2015 at 1:59 pm
  
  This is a bug indeed. A fix will be available shortly.
  Thank you!
  - Kirill Rakhman says:
    
    September 17, 2015 at 2:13 pm
    
    Might have something to do with https://youtrack.jetbrains.com/issue/KT-9186?
  - Jacob Moncur says:
    
    September 18, 2015 at 9:57 pm
    
    Seeing the same issue, what future version should a fix be available on?
  - Max says:
    
    September 23, 2015 at 6:11 pm
    
    It fixed? How long to wait?
Mohammad Shamsi says:

September 17, 2015 at 1:38 am

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 at 10:21 am
  
  You can simply use multi-line strings like """\d+""" to avoid double escaping in regex. See example.
- Oliver Weiler says:
  
  September 17, 2015 at 12:41 pm
  
  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″””
Artem Zinnatullin says:

September 17, 2015 at 4:02 am

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 at 5:39 am
  
  And here is a string that causes the exception – <![CDATA[(TA;I)TA;]]>
  - Vladimir Mironov says:
    
    September 17, 2015 at 5:46 am
    
    Ooops, it looks like WordPress has eaten a part of the string. I’m not sure how to paste it properly, so I’ll provide it as a gist https://gist.github.com/nsk-mironov/02547b0ff9a13fa4b2cc
- Loong_T says:
  
  September 17, 2015 at 6:47 am
  
  I have encountered this problem as well.
- Eugene Biletskiy says:
  
  September 17, 2015 at 2:08 pm
  
  Do you use Kotlin for apps in production?
  - Artem Zinnatullin says:
    
    September 17, 2015 at 2:38 pm
    
    It does not matter, problem needs to be fixed anyway.
    And yes, why not?
- Martynas says:
  
  September 17, 2015 at 3:46 pm
  
  Same here. Although in my case it was because of multidex, when performing task application:shrinkDebugMultiDexComponents`
- Eugene Krivenja says:
  
  September 17, 2015 at 4:34 pm
  
  Same issue
  - Eugene Krivenja says:
    
    September 17, 2015 at 4:57 pm
    
    Googled very similar issue with Scala
    http://sourceforge.net/p/proguard/bugs/309/
    The problem was in bad signatures.
    Can be a same with Kotlin?
- Alexander Udalov says:
  
  September 17, 2015 at 5:04 pm
  
  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 at 2:11 pm
    
    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 at 7:31 pm
      
      Can confirm, worked for me.
Takuya Miyamoto says:

September 17, 2015 at 7:04 am

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 at 1:17 pm
  
  Which version of Kotlin plugin have you tried to install?
  - Takuya Miyamoto says:
    
    September 17, 2015 at 5:08 pm
    
    0.13.1513.idea141.19
    
    I’ve tried to upgrade from old one.
    - Natalia Ukhorskaya says:
      
      September 18, 2015 at 6:25 pm
      
      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 at 10:04 pm
        
        A saw this error too when try to open Settings -> Kotlin Compiler tab
      - Takuya Miyamoto says:
        
        September 19, 2015 at 10:45 am
        
        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 at 11:21 am
  
  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 at 12:41 pm
    
    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 at 1:55 pm
      
      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 at 6:42 pm
        
        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 at 12:43 am
        
        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
Tyler Prete says:

September 17, 2015 at 10:55 am

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 at 2:57 pm
  
  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 at 3:50 pm
  
  Your code isn’t correct.
  
  fun main(args: Array) { fun thing(i: Int) = i + 1 (1..5).map(::thing).forEach { println(it) } }
  
  1
  2
  3
  4
  
  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 {}
Salomon BRYS says:

September 17, 2015 at 1:01 pm

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 at 1:14 pm
  
  Reflection can change final fields anyway.
  - Salomon BRYS says:
    
    September 17, 2015 at 1:40 pm
    
    That’s very sad
    - Kirill Rakhman says:
      
      September 17, 2015 at 1:41 pm
      
      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 at 1:49 pm
  
  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 at 10:04 pm
  
  https://gist.github.com/naixx/9d94c1498c4d45ffda3a
  Here is a limited version of “ternary” operator
  - Andrey Breslav says:
    
    September 18, 2015 at 2:20 pm
    
    Cool approach
Dmitry says:

September 17, 2015 at 2:22 pm

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!
Tommy Visic says:

September 17, 2015 at 11:37 pm

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)

1
2

val properties = hashMapOf<String, Any?>()
var name: String by Delegates.mapVar(properties)
- Roman Belov says:
  
  September 18, 2015 at 12:03 pm
  
  Now you can write just:
  
  import kotlin.properties.get import kotlin.properties.set ... val properties = hashMapOf<String, Any?>() var name: String by properties
  
  1
  2
  3
  4
  5
  
  import kotlin.properties.get
  import kotlin.properties.set
  ...
  val properties = hashMapOf<String, Any?>()
  var name: String by properties
  - Tommy Visic says:
    
    September 18, 2015 at 6:47 pm
    
    Ah I was missing the imports. Thanks much.
Ion says:

September 18, 2015 at 8:25 pm

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

September 18, 2015 at 9:28 pm

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 at 10:10 pm
  
  Looks fine from here. Is it still missing for you?
  - nico says:
    
    September 18, 2015 at 11:27 pm
    
    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 at 1:07 am
      
      works now
Rob Fletcher says:

September 18, 2015 at 10:21 pm

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.
CountMath says:

September 19, 2015 at 4:19 am

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?
- Andrey Breslav says:
  
  September 19, 2015 at 11:11 am
  
  First off, to have a static constant in your code, you can create a companion object for your class.
  
  Then, have a look at this blog post: http://blog.jetbrains.com/kotlin/2015/09/call-for-feedback-upcoming-changes-in-kotlin/
  It announces constants, but doesn’t say anything about inlining them. Inlining is a controversial feature, so we will consider supporting the inline modifier for constants in the future
Sven Jacobs says:

September 19, 2015 at 1:09 pm

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!
JayC says:

September 22, 2015 at 2:09 am

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 at 3:08 pm
  
  Defaults were never private
- Mykola says:
  
  September 22, 2015 at 5:07 pm
  
  I disagree. In any case most of the methods in any projects are public. So why to force developers to write extra boilerplate
Sergey says:

September 28, 2015 at 4:29 pm

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 at 7:16 pm
  
  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 at 11:12 am
    
    Didn’t help, still “arrayListOf” red-colored… How can I send JetBrains diagnostic info to investigate the case ?
    - Andrey Breslav says:
      
      September 30, 2015 at 12:00 pm
      
      Please file an issue in YouTrack
Pingback: IntelliJ IDEA 15 EAP und Kotlin M13 vereint - JAXenter