Access modifiers are an important part of object-oriented programming, as they allow you to control the visibility and accessibility of class members. In Kotlin, there are four access modifiers:

1. public
2. protected
3. private
4. internal

Each of these modifiers determines the level of visibility of a class member and how it can be accessed. In this article, we will cover each of these access modifiers in detail and discuss their interoperability with Java.

Public Visibility Modifier

In Kotlin, the public visibility modifier is used to specify that a class, method, property, or any other declaration is accessible from anywhere in your program. If you don’t specify any visibility modifier, your declaration is automatically considered public. For example:

class Person {
    var name: String = ""
    fun sayHello() {
        println("Hello, my name is $name")
    }
}

The Person class and its properties and methods are public by default, meaning that they can be accessed from anywhere in your program or external modules.

Protected Visibility Modifier

In Kotlin, the protected modifier restricts the visibility of a member to its own class and its subclasses. This means that the member can only be accessed within the class where it is declared or in any subclasses of that class.

Here’s an example to illustrate how the protected modifier works:

open class Shape {
    protected var name: String = "Shape"
    protected fun getName() {
        println(name)
    }
}

class Rectangle : Shape() {
    fun printName() {
        getName() // Accessible because it is declared as protected in the Shape class
    }
}

fun main() {
    val shape = Shape()
    shape.getName() // Not accessible because getName() is declared as protected in the Shape class
    val rectangle = Rectangle()
    rectangle.printName() // Accessible because printName() calls getName() in the Rectangle class
}

In this example, we have a Shape class with a protected property name and a protected function getName(). The Rectangle class extends the Shape class and has a function printName() that calls getName().

In the main() function, we create an instance of Shape and try to call getName(). This is not accessible because getName() is declared as protected in the Shape class. However, we can create an instance of Rectangle and call printName(), which in turn calls getName(). This is accessible because getName() is declared as protected in the Shape class and Rectangle is a subclass of Shape.

It’s important to note that the protected modifier only allows access to the member within its own class and its subclasses. It does not allow access from outside the class hierarchy, even if the class is in the same file or package.

Here’s an example to illustrate this:

package com.softaai.protected

open class Shape {
    protected var name: String = "Shape"
}

class Rectangle : Shape() {
    fun printName() {
        println(name) // Not accessible because name is declared as protected in the Shape class
    }
}

fun main() {
    val shape = Shape()
    println(shape.name) // Not accessible because name is declared as protected in the Shape class
}

In this example, we have a Shape class with a protected property name and a Rectangle class that extends Shape. We also have a main() function in the same file that tries to access the name property of a Shape instance. However, this is not accessible because name is declared as protected in the Shape class, and the main() function is not part of the Shape class hierarchy.

Java interoperability of Protected Modifier

In Kotlin, a protected member is visible to its own class and its subclasses, just like in Java. When a Kotlin class is compiled to bytecode, its protected members are marked with the protected modifier in the bytecode, which allows Java classes to access them.

Here’s an example to illustrate this:

// Kotlin code
open class Shape {
    protected var name: String = "Shape"
}

class Rectangle : Shape() {
    fun printName() {
        println(name) // Accessible because name is declared as protected in the Shape class
    }
}

// Java code
public class Main {
    public static void main(String[] args) {
        Rectangle rectangle = new Rectangle();
        rectangle.printName(); // Accessible because it calls getName() which is declared as protected in the Shape class
        System.out.println(rectangle.name); // Not accessible because name is declared as protected in the Shape class
    }
}

In this example, we have a Shape class with a protected property name and a Rectangle class that extends Shape. In the Kotlin code, the printName() function calls the name property, which is declared as protected in the Shape class. In the Java code, we create an instance of Rectangle and call printName(), which calls the name property. This is accessible because name is declared as protected in the Shape class, and Rectangle is a subclass of Shape.

However, we also try to access the name property directly from the Rectangle instance, which is not allowed because name is declared as protected and can only be accessed from within the class hierarchy.

Private Visibility Modifier

In Kotlin, you can use the private visibility modifier for classes, methods, properties, and any other declaration to restrict their visibility to the file where they are declared. This means that other files or classes in your program or external modules cannot access them. For example:

private class Secret {
    fun tellSecret() {
        println("The secret is safe with me.")
    }
}

In this example, the Secret class is private, and its tellSecret() method is accessible only within the file where it’s declared. Other files or external modules cannot access the Secret class or its methods.

Internal Visibility Modifier

The default visibility in Java, package-private, isn’t present in Kotlin. Kotlin uses packages only as a way of organizing code in namespaces; it doesn’t use them for visibility control. As an alternative, Kotlin offers a new visibility modifier, internal, which means “visible inside a module.” A module is a set of Kotlin files compiled together. It may be an IntelliJ IDEA module, an Android Studio or Eclipse project, a Maven or Gradle project, or a set of files compiled with an invocation of the Ant task. Internal visibility allows you to hide your implementation details and provide real encapsulation for your module. For example:

package com.softaai.mymodule

internal class MyClass {
    internal var myField = 42

    internal fun myMethod() {
        println("Hello, world!")
    }
}

In this example, the MyClass class is marked as internal, and so are its myField field and myMethod method. This means that they can only be accessed within the same module.

Now, suppose you have another Kotlin module that wants to use MyClass, but can only access its public API:

package com.softaai.myothermodule

import com.softaai.mymodule.MyClass

class MyOtherClass {
    private val myClassObject = MyClass()

    fun doSomething() {
        myClassObject.myField = 100 // compilation error: 'myField' is internal and cannot be accessed outside the module
        myClassObject.myMethod() // compilation error: 'myMethod' is internal and cannot be accessed outside the module
    }
}

In this example, the MyOtherClass class is in a different module than MyClass, and can only access MyClass‘s public API. When MyOtherClass tries to access myField and myMethod, which are both marked as internal, it will result in compilation errors. This is because the internal modifier provides real encapsulation for the implementation details of the MyClass module, preventing external code from accessing and modifying its internal declarations.

Kotlin’s visibility modifiers and Java

Kotlin’s visibility modifiers and their default visibility rules are interoperable with Java, which means that Kotlin code can call Java code and vice versa.When Kotlin code is compiled to Java bytecode, the visibility modifiers are preserved and have the same meaning as in Java(one exception: a private class in Kotlin is compiled to a package-private declaration in Java). This means that you can use Kotlin declarations from Java code as if they were declared with the same visibility in Java. For example, a Kotlin class declared as public will be accessible from Java code as a public class.

However, there is one exception to this rule. In Kotlin, a private class is compiled to a package-private declaration in Java. This means that the class is not visible outside of the package, but it is visible to other classes within the same package.

The internal modifier in Kotlin is a bit different from the other modifiers, because there is no direct analogue in Java. In Java, package-private visibility is a different concept that does not correspond exactly to Kotlin’s internal visibility.

When Kotlin code with an internal modifier is compiled to Java bytecode, the internal modifier becomes public. This is because a module in Kotlin may contain declarations from multiple packages, whereas in Java, each package is self-contained.

This difference in visibility between Kotlin and Java can sometimes lead to unexpected behavior. For example, you may be able to access an internal class or a top-level declaration from Java code in another module, or a protected member from Java code in the same package. These scenarios are similar to how you would access these elements in Java.

However, it’s important to note that the names of internal members of a class are mangled. This means that they may look ugly in Java code, and are not meant to be used directly by Java developers. The purpose of this is to avoid unexpected clashes in overrides when you extend a class from another module, and to prevent accidental use of internal classes.

Let’s say you have a Kotlin class with an internal function:

package com.softaai.internal

class MyClass {
    internal fun myFunction() {
        println("Hello from myFunction!")
    }
}

When compiled to bytecode and viewed from Java, the myFunction method will have a mangled name that includes the package name and a special prefix to indicate its visibility. The mangled name might look something like this:

public final void com.softaai.internal.MyClass$myFunction() {
    // implementation of myFunction
}

As you can see, the mangled name includes the package name and the name of the class, with a $ separator followed by the original name of the method. This naming convention helps to prevent naming clashes and ensures that the method is only accessible within the module where it was defined.

Conclusion

Kotlin’s access modifiers provide a way to control the visibility of code within a module and ensure better encapsulation. They also map well to Java access modifiers, which makes Kotlin code fully interoperable with Java. When working with both Kotlin and Java code, it’s important to understand how access modifiers are represented in both languages to ensure that code is visible only where it’s intended to be visible.