we just published an update to 1.1-M03 plugins which fixes the issue with Java packages not resolving

K 1.0.6 EAP is available: https://discuss.kotlinlang.org/t/kotlin-1-0-6-eap/2117

and it’s still unable to compile our project 😞

@vmironov Can you reproduce it in some smaller project?

How do we use kapt3 in 1.0.6?

If it's still just using the

apply plugin: 'kotlin-kapt'

kapt3 is even more broken than 1.0.4. 😞

If you have any problems that are not covered by issues above, please open the new issue. The new kapt is still considered as an experimental feature, and there could be different kinds of issues right now.

Coroutines question: Now that the JS backend supports coroutines, can I serialize a coroutine on the JVM and have it resume in JavaScript?

@Ian no, it's not possible now and it is not planned for near future. Feel free to create an issue.

@bashor Ok, will do. Would it be possible to do the conversion from JVM to JavaScript through reflection?

Do you mean state?

@bashor Yes, to serialize the state of a continuation on the JVM, and have it resume on JavaScript

@bashor If you could do that, you could potentially build a web framework that made the distinction between code running on the browser, and code running serverside virtually invisible to the programmer

Theoretically it's possible, but if it will be done outside the compiler (sources) it will be too fragile

@bashor FYI - issue created: https://youtrack.jetbrains.com/issue/KT-15003

is serializable coroutines on roadmap for JVM backend?

⬆️ @denis.zharkov

Aren’t they already serializable?

@Ian the problem with serializable coroutines is that you can't control what you should serialize. Coroutines can be closures, so to serialize them you have to serialize outer scope, including

this

, and, possible, all outer

this

.

@alexey.andreev So just throw a NotSerializableException ?

Things like "outer this", copies of variables from outer scope, etc, usually stored in

synthetic

fields. Java serialization does not serialize

synthesic

fields

Also, what if your coroutine in JVM lives under Spring or Java EE container. Say, it sees injected field. You'll end up with serializing entire Spring context

What if your coroutine deals with JPA entities?

@alexey.andreev So just throw a NotSerializableException ?

You'll end up with NSE too often. This won't be a practical solution

This is probably where my http://swarmframework.org/ proposal comes in

How are you going to handle migration?