Do `const val` affect/hinder incremental compilati...

# compiler

[louiscad]

Do const val affect/hinder incremental compilation in ways plan val don't, granted their value don't change, but something else changed in the host class (e.g. a new constant or property)?

[gildor]

also would like to know this

In Java + Gradle any change of constant cause full recompilation of everything (probably except modules' covered with compilation avoidance)

[ephemient]

const val gets inlined at the usage site, so if you change them, all users do have to be recompiled

[ephemient]

it follows the behavior of constant static final primitive and String fields in Java

[louiscad]

@ephemient That's not the question I asked. I asked if the constant doesn't change.

[ephemient]

it does answer @gildor though

[kralli]

Taking to this blog post into account, I would say that using/not using const has no affect on the incremental compilation in this particular case. There would be no change in the ABI of that property and therefor no cause for additional recompilation.

[louiscad]

It's unclear to me if the ABI is evaluated at such a granular level. @abreslav do you know the answer to my original question? That'd help me make a decision for an open source Gradle plugin.

[kralli]

Well, I don’t think there’s much room for different levels of granularity here. Comparing ABIs leaves you with basically only two options: to see if there is any difference at all or to work out the differences declaration-wise. I don’t know the exact current state, but in the long run, they will be doing it on a per-declaration basis.

[gildor]

all users do have to be recompiled

@ephemient I understand that it inlined, but my question: “all users will be recompiled” or “all modules which have this module in dependencies”. Because second is how it works on Java with Gradle, essentially constant kills any kind of incrementality, there is no mechanism to track who is using constant, every class which in theory have access to constant will be recompiled

[ephemient]

@gildor it's difficult for the build system to keep track of who uses every constant - it could be exported as another constant again

[gildor]

I understand it :)

[ephemient]

https://blog.gradle.org/incremental-compiler-avoidance it looks like gradle attempts to be smart and look for values equal to the old value of the constant

[gildor]

I’m asking not in theory, but maybe anyone test this

[louiscad]

@ephemient Is it any easier for fields or method calls (aka. non const properties in Kotlin)?

[gildor]

I always have bad feelings about usage constants

[gildor]

@ephemient I’m aware about Gradle behaviour for Java, and this case works only for cases when constant is not changed, it still “recompile the world” (minus compilation avoidance) in case if constant is changed
Actually if Kotlin doesn’t do this, it even worse

[gildor]

so my point, if it works like this in Kotlin (or even without smart constatn check) I would just stop using constants completely, but I actually was never able to find time to check this

[ephemient]

@gildor I read that article as "if constant changed, then any classes that contain a value equal to the old constant might have used it so recompile, but classes which did not contain a value equal to the old constant definitely weren't using it"

[gildor]

Is it any easier for fields or method calls

@louiscad Yes, class level property doesn’t have such issues, because it not inlined, Gradle team recommends never use constatns

[ephemient]

I'm not sure exactly what Gradle considers part of the ABI for Kotlin

[louiscad]

Does it mean that all the folks using const val for their dependency notations declared in buildSrc should drop the const keyword @gildor?

[ephemient]

but if you add a field or method, that changes the @kotlin.Metadata annotation

[ephemient]

@louiscad for current gradle, if you're using kotlin dsl, any change to buildSrc (const or not) results in recompile https://github.com/gradle/gradle/issues/9224

[louiscad]

@ephemient Not in Gradle 6.8: https://docs.gradle.org/6.8-milestone-1/release-notes.html

[gildor]

Does it mean that all the folks using const val for their dependency notations declared in buildSrc should drop the const keyword

I think buildSrc is another problem, any change in buildSrc cause full recompilation of everything, so const probably not worse than any other change (at least from 6.8 it only related to ABI changes)

[gildor]

I read that article as

@ephemient I see you point, completely forgot about this optimization.
But now returning to my question, how does it work with Kotlin compiler? probably it just doesn’t work

[gildor]

not sure exactly what Gradle considers part of the ABI for Kotlin

It’s not really Gradle responsibility, Gradle manages Java compiler, it’s part of it, but not Kotlin, all incrementallity for Kotlin is a part of Kotlin Plugin, not Gradle

[louiscad]

I'm using buildSrc as an example, but it's not my use case, I'm working on a Gradle plugin that provides constants to be used in the Gradle scripts.

[ephemient]

6.8 isn't released yet

[gildor]

constant is not very good for public API in any case, especially if there is a big chance of changing of this constant

[ephemient]

that same optimization should work the same for kotlin since that's a property of the .class files

[gildor]

Anyway, Gradle and Kotlin DSL has own huge can of worms in terms of incrementality

[gildor]

that same optimization should work the same for kotlin since that’s a property of the .class files

No, I’m very doubt about it

[louiscad]

@gildor This is a special kind of public API, where we only care about source compatibility, and where we have a way to automatically migrate usages.

[ephemient]

what I don't know is how @Metadata and compile avoidance play together

[gildor]

because this is part of Java compilation, not a part of Kotlin compilatiion

[ephemient]

actually come to think of it, even in Java, adding a method can break source compatibility by creating an ambiguous overload

[gildor]

@louiscad I just mean, that constant in any case cause more chance for recompilation than classes

I wouldn’t bother with constants for Gradle plugin

[ephemient]

so that's not a kotlin-specific issue

[ephemient]

but for kotlin, adding top-level functions and extensions could break source compatibility even in files that didn't explicitly use that class before, so I guess any ABI change may force strictly more users to recompile than java

[abreslav]

I can’t say I understand you initial theory: ABI is tracked declaration-by-declaration, so presence of const val’s shouldn’t affect the case of changes to other members. Why do you think it might?

[louiscad]

I think I misunderstood the actual impact of const val, and got confused when I read that some parts of incremental compilation can still be improved.

I read parts of the blog post again, and it made more sense to me and I understood there should not be any impact regarding non changing `const val`s. Now, I discovered other reasons to use a plain val for the use case I have, but it's great to see that const val are not worse than val if you know you'll never, or rarely change them and binary compatibility is not a concern regarding their value.