Hello! Hope this is the right channel to ask. I ha...

# gradle

[Alexei Artsimovich]

Hello!
Hope this is the right channel to ask.
I have a question: does the internal keyword play role in compilation avoidance in Kotlin?

There is a new approach to incremental compilation in Kotlin, which improved compilation avoidance for ABI-compatible changes. https://blog.jetbrains.com/kotlin/2022/07/a-new-approach-to-incremental-compilation-in-kotlin 1
I wonder if the internal keyword plays a role in this. Should classes and methods that are not intended to be used outside a module be marked with the internal visibility so that changes to their signature do not cause dependent modules to be recompiled?

[Javier]

I would like to know about this as you can call internal declaration in other modules if you suppress the error. So I don’t know if internal can be used to avoid recompilations

[ephemient]

internal is also effectively public to any Java code, as well as public inline usages of @PublishedApi internal, so it does form part of the ABI

[Evgenii Mazhukin]

Hello! For compilation avoidance purposes, Kotlin treats internal same way as public . As @Javier and @ephemient pointed out, there are ways to call other module's internal API.

However, part of the compileKotlin task's job is to calculate which files should be recompiled. If it is an incremental build, and dependent module doesn't use the changed APIs, for JVM we would not actually recompile any files in that module.

We're interested in improving compilation avoidance in that area, but there are no specific plans yet. Please vote on the issue if you feel that it strongly affects your projects: https://youtrack.jetbrains.com/issue/KT-63830/Compilation-avoidance-should-ignore-internal-changes-if-possible

To summarize: no avoidance. Nonetheless, it's a good idea to mark an API internal, if it's intended to be internal. It would help your collaborators use proper APIs in their code. And, well, code is for people, compiler just makes it work.