<@U2E974ELT> can we make `CoroutineContext#DEBUG` ...

# coroutines

[Dmytro Danylyk]

@elizarov can we make CoroutineContext#DEBUG field public and mutable? In android we usually rely on generated BuildConfig.DEBUG field.

[elizarov]

I’m not sure I follow the use-case

[Dmytro Danylyk]

I want to set CoroutineContext#DEBUG field based on if it’s android debug or production build.

[Dmytro Danylyk]

In android we have generated BuildConfig.DEBUG field which is false if it’s debug build and true if it;s prodcution.

[Dmytro Danylyk]

So example of usage on android would be something like: CoroutineContext.DEBUG = BuildConfig.DEBUG

[Dmytro Danylyk]

For now I can do this via reflection. Let me know if you want me to create ticket and describe use-case. I think I can contribute as well.

[elizarov]

I see. You have different kinds of builds…

[Dmytro Danylyk]

So, is there any reason to not make it possible to change CoroutineContext#DEBUG ?

[Vsevolod Tolstopyatov [JB]]

The good thing about the immutability of static final variable is that JIT can inline it everywhere and eliminate unnecessary branches/checks etc., so debug code has no influence on performance with debug mode off.
Why changing DEBUG via kotlinx.coroutines.debug system property is not applicable?

[kenkyee]

Android's BuildConfig.DEBUG is also static final FWIW

[Dmytro Danylyk]

@Vsevolod Tolstopyatov [JB] because we don't want to have debug flag's all over the places. We usually have single source file (Application class) where we do all initialisation, e.g. we initialise image loader with debug logs, http client with debug logs, etc. And everything is controlled via BuildConfig.DEBUG flag.

[Dmytro Danylyk]

See this answer https://stackoverflow.com/a/39589492

[Vsevolod Tolstopyatov [JB]]

@Dmytro Danylyk why calling System.setProperty("kotlinx.coroutines.debug", "on") depending on BuildConfig.DEBUG in the beginning of Application class is not applicable in such case?

[elizarov]

We can also support “injectable” providers for DEBUG via META-INF/services extension mechanism where you’d provide your own implementation of the class that returns debug status. This way, too, we can keep it static final field, yet allow for project-specific configuration.

[Dmytro Danylyk]

@Vsevolod Tolstopyatov [JB] this will work, however: it’s not type safe and you need to write mapping between BuildConfig.DEBUG true/false and coroutine DEBUG on/off/auto.

[Dmytro Danylyk]

Would be great at least have private const val DEBUG_PROPERTY_NAME = "kotlinx.coroutines.debug" public

[Dmytro Danylyk]

@elizarov not sure if it will work for android, I never tried to do this.

[Dmytro Danylyk]

let’s continue in https://github.com/Kotlin/kotlinx.coroutines/issues/316, I think as a first step making constants public would be great step forward.