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:
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 var
s, 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
topublic
, - 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 iffoo
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
andartifactId
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!
cypressious says:
September 16, 2015Great news! How is incremental Gradle compilation coming along?
Ivan Nikitin says:
September 16, 2015Andrey, 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, 2015Figured 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.
Mounir Boudraa says:
September 16, 2015What about Anko. Will it be updated to kotlin m13 ?
Yan Zhulanow says:
September 17, 2015I am going to release the M13-compatible version today. Please stay tuned!
Mounir Boudraa says:
September 18, 2015Thanks. Well received 😉
Brian says:
September 16, 2015Thanks 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, 2015I 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, 2015My temporary solution is:
val customLayout = findViewById(R.id.customLayout) as CustomLayout
instead of synthetic property
Yan Zhulanow says:
September 17, 2015This is a bug indeed. A fix will be available shortly.
Thank you!
Kirill Rakhman says:
September 17, 2015Might have something to do with https://youtrack.jetbrains.com/issue/KT-9186?
Jacob Moncur says:
September 18, 2015Seeing the same issue, what future version should a fix be available on?
Max says:
September 23, 2015It fixed? How long to wait?
Mohammad Shamsi says:
September 17, 2015Great 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, 2015You can simply use multi-line strings like
"""\d+"""
to avoid double escaping in regex. See example.Oliver Weiler says:
September 17, 2015There 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, 2015We 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, 2015And here is a string that causes the exception – <![CDATA[(TA;I)TA;]]>
Vladimir Mironov says:
September 17, 2015Ooops, 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, 2015I have encountered this problem as well.
Eugene Biletskiy says:
September 17, 2015Do you use Kotlin for apps in production?
Artem Zinnatullin says:
September 17, 2015It does not matter, problem needs to be fixed anyway.
And yes, why not? 🙂
Martynas says:
September 17, 2015Same here. Although in my case it was because of multidex, when performing task
application:shrinkDebugMultiDexComponents`
Eugene Krivenja says:
September 17, 2015Same issue
Eugene Krivenja says:
September 17, 2015Googled 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, 2015This 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, 2015Update: the problem has been fixed and the new build 0.13.1514 is now released, please try it out.
Karol says:
September 22, 2015Can confirm, worked for me.
Takuya Miyamoto says:
September 17, 2015In 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, 2015Which version of Kotlin plugin have you tried to install?
Takuya Miyamoto says:
September 17, 20150.13.1513.idea141.19
I’ve tried to upgrade from old one.
Natalia Ukhorskaya says:
September 18, 2015Was 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, 2015A saw this error too when try to open Settings -> Kotlin Compiler tab
Takuya Miyamoto says:
September 19, 2015It 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, 2015When 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, 2015Have 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, 2015Thanks 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, 2015Seems 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, 2015Natalia 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, 2015Was 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, 2015UPD: 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, 2015Your 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 {}
Salomon BRYS says:
September 17, 2015Hi 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, 2015Reflection can change final fields anyway.
Salomon BRYS says:
September 17, 2015That’s very sad
Kirill Rakhman says:
September 17, 2015It’s a security risk in some cases, but also useful in other cases. It’s how the JVM works.
Andrey Breslav says:
September 17, 2015You 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, 2015https://gist.github.com/naixx/9d94c1498c4d45ffda3a
Here is a limited version of “ternary” operator 🙂
Andrey Breslav says:
September 18, 2015Cool approach 🙂
Dmitry says:
September 17, 2015Wow, “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, 2015Thanks 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:
September 18, 2015Now you can write just:
Tommy Visic says:
September 18, 2015Ah I was missing the imports. Thanks much.
Ion says:
September 18, 2015Hello,
What about libraries like kotlin-swing and kotlin-jdbc
they are still M12
nico says:
September 18, 2015Was 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, 2015Looks fine from here. Is it still missing for you?
nico says:
September 18, 2015wget “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, 2015works now
Rob Fletcher says:
September 18, 2015Great 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, 2015Awesome 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, 2015First 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: https://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 futureSven Jacobs says:
September 19, 2015lateinit 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, 2015I 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, 2015Defaults were never private
Mykola says:
September 22, 2015I 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, 2015After 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, 2015Looks like there’s an issue with your IDE/setup. Please try to invalidate IDE caches: File -> Invalidate Caches / Restart…
Sergey says:
September 29, 2015Didn’t help, still “arrayListOf” red-colored… How can I send JetBrains diagnostic info to investigate the case ?
Andrey Breslav says:
September 30, 2015Please file an issue in YouTrack
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. […]