This message was deleted.

hmmm. A few thoughts: • Using project inside of a task falls afoul of CC / project isolation and shouldn’t be done, regardless of

lazy

. Generally values like that would be provided at task registration time (by a plugin or build script author). Besides,

findProperty

is trivial and not worth making lazy (Gradle implicitly does that for you via providers.gradleProperty wired into task properties) •

lazy

on a private class val is likely OK. This gets problematic for static /singleton items (companion objects, etc), as the Gradle Daemon remains running serving multiple builds (which may not play well with static state)

I see a lot of

project.findProperty()

where they probably mean

project.extra[]

, fwiw.

yea. they are both a straightforward lookup and not worth fretting about the performance, and should not be done inside of a task.

I've only needed to do so to avoid the IDE yelling about

LeakingThis

warnings when I have derived read-only properties.

in most cases of conventional use of Gradle properties you can ignore

LeakingThis

, though its worth reading up on the risks to ensure you don’t stray into problematic areas.

I see a lot of

project.findProperty()

where they probably mean

project.extra[]

, fwiw.

If they mean that, then they are following bad practices. 😉 Extra properties are almost always just a quick-and-dirty work-around for not doing it the proper way. In most cases is is for example better to register an extension with fields, that are then also properly typed and can be accessed by accessors.

It is a function of the age of the code I have to work with, and around.