If you already have a large library, you're probably wondering how much work this might be. On the other hand, the warning mode is far more forgiving, showing warnings for those declarations.

The strict mode will throw an error for each declaration that doesn't comply with the Explicit API mode. '-Xexplicit-api=strict', // or '-Xexplicit-api=warning' When Kotlin is compiled, it will mangle the names of methods, properties, etc, that have been marked as internal to prevent their misuse by Java consumers.Ĭonsidering the following example, the internal bar() method is visible and accessible by Java consumers as bar$foo_sdk_name_class_name() Since the internal keyword is not something Java understands, a Java consumer is capable to access internal Kotlin APIs. This is an efficient way to limit what is available to your consumers while fully allowing its usage inside your module. This visibility is similar to the package-private visibility in Java, but instead it's private to the entire module. Our best friend to keep implementation details out of the public API is the internal keyword. Let's take a look at some visibility options that Kotlin provides. Even when a module is meant to be consumed by a single application, it's best to treat it as a fully independent piece of software - as it is. While this article is focused on libraries, the same is applicable to multi-module projects. Additionally, when changes are made to the actual implementations, it prevents making breaking changes by mistake. This will lead to more concise and easier to use APIs, indirectly, resulting in easier-to-maintain projects. It is often good practice minimizing the libraries' functionality that is accessible to consumers. This means types, methods, properties, etc. When designing libraries, one important aspect is the public API surface.

Internal kotlin modifier