Coroutines: Support class reloading used by tools like Play framework and SBT

Support
1

Currently, Play framework (Java version) uses SBT to reload classes on their change by compiling changed classes and restarting class loaders of running app. Everything was ok until I added kotlin coroutines to a controller and then when developing on that controller, every time I change the code, I must restart server which takes very long time.
Is there any way to work around this?

1 Like
2

Can you provide a link to some self-contained project that reproduces this problem?

3

FWIW, I’m experiencing a lot of hot reloading problems with Android since introducing coroutines. Basically, I had to turn the feature off. Right now it won’t even compile:

      Error:Execution failed for task ':app:transformClassesWithDexBuilderForDebug'.
      > com.android.build.api.transform.TransformException: org.gradle.tooling.BuildException:   com.android.dx.cf.code.SimException: local 0007: invalid
4

Can you elaborate on the problem? Can you reproduce with a self-contained example or post your project?

5

I’m using Android Studio 3.0 beta 6 with Kotlin 1.1.4-2. The project uses Anko and this library: GitHub - lightningkite/kotlin-anko

Steps to reproduce:

  1. enable Instant Run in Settings
  2. build the project
  3. run the project
    => exception as above. Stack trace from the Gradle console:
:app:transformClassesWithDexBuilderForDebug
Error while processing com\lightningkite\kotlin\anko\HintSpinner.class
com.android.dx.cf.code.SimException: local 0007: invalid
	at com.android.dx.cf.code.OneLocalsArray.throwSimException(OneLocalsArray.java:243)
	at com.android.dx.cf.code.OneLocalsArray.get(OneLocalsArray.java:155)
	at com.android.dx.cf.code.BaseMachine.localArg(BaseMachine.java:211)
	at com.android.dx.cf.code.Simulator$SimVisitor.visitLocal(Simulator.java:604)
	at com.android.dx.cf.code.BytecodeArray.parseInstruction(BytecodeArray.java:368)
	at com.android.dx.cf.code.Simulator.simulate(Simulator.java:103)
	at com.android.dx.cf.code.Ropper.processBlock(Ropper.java:790)
	at com.android.dx.cf.code.Ropper.doit(Ropper.java:745)
	at com.android.dx.cf.code.Ropper.convert(Ropper.java:350)
	at com.android.dx.dex.cf.CfTranslator.processMethods(CfTranslator.java:309)
	at com.android.dx.dex.cf.CfTranslator.translate0(CfTranslator.java:150)
	at com.android.dx.dex.cf.CfTranslator.translate(CfTranslator.java:102)
	at com.android.builder.dexing.DxDexArchiveBuilder.dex(DxDexArchiveBuilder.java:115)
	at com.android.builder.dexing.DxDexArchiveBuilder.convert(DxDexArchiveBuilder.java:85)
	at com.android.build.gradle.internal.transforms.DexArchiveBuilderTransform$DexConversionWorkAction.run(DexArchiveBuilderTransform.java:433)
	at com.android.build.gradle.internal.transforms.DexArchiveBuilderTransform.lambda$convertToDexArchive$1(DexArchiveBuilderTransform.java:519)
	at java.util.concurrent.ForkJoinTask$AdaptedCallable.exec(ForkJoinTask.java:1424)
	at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
	at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
	at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
	at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)

Looking at the stack trace, I’m not sure it’s even related to coroutines, though…

6

Looking at the stack trace it does not even seem to be related to Kotlin, but looks like a bug in a beta version of Android toolchain. I would highly recommend reporting it to Google Android team.

7

I did have problems with coroutines before I started using this library, though. Pretty sure it was related to using Anko’s onClick. “Apply changes” would result in runtime exception after I did something with the GUI.