См. https://blog.jetbrains.com/kotlin/2015/06/better-annotation-processing-supporting-stubs-in-kapt/ (заглушки описаны во втором абзаце, но первый предоставляет контекст):
Первоначальная версия kapt, обработанная путем перехвата связи между аннотациями процессоры (например, Dagger 2) и javac, и добавили уже скомпилированные классы Kotlin поверх классов Java, которые javac видели в источниках. Проблема с этим подходом заключалась в том, что, поскольку Kotlin классы должны были быть уже скомпилированы, у них не было никакого способа сослаться на какой-либо код, сгенерированный процессором (например, классы модулей Dagger). Таким образом, нам пришлось написать классы приложений Dagger в Java.
. Как обсуждалось в предыдущем сообщении в блоге, эту проблему можно преодолеть путем создания заглушек классов Kotlin перед запуском javac и затем запуск реальной компиляции после завершения javac. Заглушки содержат только объявления и не содержат тел методов. Компилятор Kotlin в любом случае использовался для создания таких заглушек в памяти (они используются для взаимодействия Java, когда код Java ссылается на Kotlin), поэтому все, что нам нужно было сделать, это сериализовать их в файлы на диске.
А также этот ответ .
Но теперь заглушки генерируются по умолчанию, вы можете явно отключить это поколение, используя aptMode=apt или , только генерировать заглушки, используя aptMode=stubs. Я думаю, что они в первую очередь предназначены для внутреннего использования системами сборки (например, Gradle), как описано в https://www.bountysource.com/issues/38443087-support-for-kapt-for-improved-kotlin-support:
Там есть 4 шага.
- kaptGenerateStubs Kotlin: запустить kotlinc с плагином: org.jetbrains. kotlin .kapt3: aptMode = stubs
- kaptKotlin запустить kotlinc с плагином: org.jetbrains. kotlin .kapt3: aptMode = apt
- compileKotlin run kotlinc регулярно
- compileJava run javac с -pro c: нет и передавать сгенерированный исходники из шага 2.
Эти шаги немного отличаются для каждой вспомогательной версии kotlin, поэтому это будет интересно.