Convert to Java, use Worker API

[benjamin-bader]

This is the saddest issue.

Gradle bundles its own Kotlin runtime and makes no guarantee about compatibility with third-party Kotlin code. Per Gradle, the only safe and forwards-compatible way to use Kotlin in a plugin is via the Worker API, using classpath isolation.

This means that our code cannot be Kotlin, and since we have Kotlin dependencies, they can only safely be used from behind that classpath-isolated worker.

The plan:

• Convert Plugin.kt to several Java classes - a base Plugin, and moving the applicators to individual Java files
  • the official AGP API is Kotlin which is going to be trouble. Java's the lowest common denominator, so we can do it, but it'll be ugly
• Either convert the tasks to Java, or move them to an impl module and depend on it dynamically. Probably better to just move them over to Java.

Checklist:

• DexCountExtension
• DexCountException
• Deobfuscator
• ColorConsole.kt
• GradleApi.kt
• OutputFormat
• PackageTree
• PrintOptions
• SourceFile.kt
• Thrifty.kt (maybe we can solve this by bumping to 3.0.0-RC01 which has this stuff built in?)
• GeneratePackageTreeTask
• DexCountOutputTask
• CountReporter
• DexMethodCountPlugin
• TaskApplicators

[nevack]

Seems quite painful

[benjamin-bader]

Yep. Very much so. This is the second major language change for this project. Initially it was Groovy, because who wants to write Java? Eventually, I got so fed up with maintaining hacks around Gradle's Groovy version changes that I jumped to Kotlin as soon as possible. I have no desire to repeat the hacks a second time around.

When a principal engineer at Gradle tells me "Kotlin runtimes are controlled by us now and are subject to change", I see the writing on the wall.

[benjamin-bader]

In other words, my hope is that the pain and effort now offset even greater pain in the future.

[benjamin-bader]

It's done