The Tyranny of kotlin’s default

As Halloween flies by and we dress up as ghouls, ghosts and other things that go bump in the night, it occurred to me that one of the the scariest things to an Android developer (outside of Out Of Memory exceptions, of course) are unexpected breaking changes in an API when you upgrade a dependency. There are a few reasons that this can happen. Maybe the author has decided to take the API in a different direction. This is one of the good reasons. Unfortunately, there are a lot of bad ones too. One of the worst reasons breaking changes can happen is because the author of the library removed members from API that you depended on but that they never intended for you to have access to in the first place. In this post, I want to look at why utilizing Kotlin at first seems to help with this issue and where it falls short. I also want to examine why it is important that app developers need to start borrowing a few best practices from library developers and should start to pay attention to the proper use of visibility modifiers as well.

To begin, lets review java’s default visibility, package-private.

Visibility Refresher

As you most likely know, java by default gives you package-private visibility. This visibility would allow only for same package access. This modifier does not have a kotlin analogue. Anyone who has tried to write a library would let you know that this modifier was less than ideal for trying to stop clients from accessing your code. One of the reasons for this was as soon as your library grew from one package in size, the only way for code to access each other across packages (outside of using protected for inheritance) was the public modifier. The negative consequence now being that all the clients of the library now have access to those components as well. And that is one of the reasons why kotlin dropped this visibility modifier and instead opted for a new visibility modifier labeled “internal”.

kotlin’s internal visibility modifier

The new visibility modifier, internal, essentially means “visible inside a module”. Now, what is a module exactly you might ask? In this context, a module is any code that is compiled together. We can look at the current definition of internal visibility taken straight from the official kotlin documentation by JetBrains for further elaboration:

The internal visibility modifier means that the member is visible within the same module. More specifically, a module is a set of Kotlin files compiled together:

an IntelliJ IDEA module;

a Maven project;

a Gradle source set;

a set of files compiled with one invocation of the Ant task.

So as you can see, this is exactly what you would want as a library developer. Now anything I mark internal can be seen only by my library code, however I am not necessarily restricted by packages. Much Better!

So what does this mean for app developers?

But so what does this mean for app developers. If you’re developing an app with all your code in one app module than internal will behave as public. No difference for you.

However, this is 2017! With instant apps, tools like Buck and the Android Gradle Plugin 3.0 offering better parallelism for multi-module projects, it is obvious that the future of Android development will be multi-module based. Coding an entire Android app in a single app module was sooo last week. When we build modules, we have to begin to think (at least at a little) like library developers. One of the ways in which we should start thinking like library developers is to utilize access modifiers to facilitate the encapsulation of components in our non-app modules.

Tyranny of the default

So now we have switched to kotlin and we have access to the internal visibility modifier and all is good in the world, right? Well, not exactly… Kotlin by default, assigns everything public visibility. The consequence of this is now every top-level function, class, etc. must be explicitly assigned internal (or a smaller scope) visibility if you don’t want it to be a part of your module’s API. As any reader of Effective Java would tell you, refactoring the module is now more likely to cause breaking changes outside of that module as it is more likely that classes, interfaces or members of the class are inadvertently exposed. Less than ideal.

The Current State of Affairs

Did Kotlin take one step forward by giving us the internal visibility modifier but two steps back by making public the default?

Not quite. Kotlin, even though it was designed to enforce best practices, it was also designed for brevity. Now you might say this is arguable and that’s because it is and was argued against by some (including some highly recognizable names in the Android community) but to no avail.

All in All…

As modern day Android projects move towards using a multi-module based architecture, being able to take advantage of the kotlin internal modifier to ensure the smallest exposed API for your modules is just another reason to make the switch to kotlin. However, for better or worse, kotlin’s default visibility is public and while this is still a much larger problem/inconvenience for library developers, as app developers, have to keep this in mind as we inch closer to multi-module based app architectures.

P.S.

It should be noted that, there is a kotlin KEEP to get rid of a default visibility modifier entirely for library developers. Thats a start!