Java ‘public’ Access Modifier

1. Overview

In this quick article, we’ll cover the public modifier in-depth, and we’ll discuss when and how to use it with classes and members.

Additionally, we’ll illustrate the drawbacks of using public data fields.

For a general overview of access modifiers, definitely have a look at our article on Access Modifiers in Java.

2. When to Use the Public Access Modifier

Public classes and interfaces, along with public members, define an API. It’s that part of our code that others can see and use to control the behavior of our objects.

However, overusing the public modifier violates the Object-Oriented Programming (OOP) encapsulation principle and has a few downsides:

• It increases the size of an API, making it harder for clients to use
• It’s becoming harder to change our code because clients rely on it — any future changes might break their code

3. Public Interfaces and Classes

3.1. Public Interfaces

A public interface defines a specification that can have one or more implementations. These implementations can be either provided by us or written by others.

For example, the Java API exposes the Connection interface to define database connection operations, leaving actual implementation to each vendor. At run-time, we get the desired connection based on the project setup:

Connection connection = DriverManager.getConnection(url);

The getConnection method returns an instance of a technology-specific implementation.

3.2. Public Classes

We define public classes so that clients can use their members by instantiation and static referencing:

assertEquals(0, new BigDecimal(0).intValue()); // instance member
assertEquals(2147483647, Integer.MAX_VALUE); // static member

Moreover, we can design public classes for inheritance by using the optional abstract modifier. When we’re using the abstract modifier, the class is like a skeleton that has fields and pre-implemented methods that any concrete implementation can use, in addition to having abstract methods that each subclass needs to implement.

For example, the Java collections framework provides the AbstractList class as a basis for creating customized lists:

public class ListOfThree<E> extends AbstractList<E> {

    @Override
    public E get(int index) {
        //custom implementation
    }

    @Override
    public int size() {
        //custom implementation
    }

}

So, we only have to implement the get() and size() methods. Other methods like indexOf() and containsAll() are already implemented for us.

3.3. Nested Public Classes and Interfaces

Similar to public top-level classes and interfaces, nested public classes and interfaces define an API datatype. However, they are particularly useful in two ways:

• They indicate to the API end user that the enclosing top-level type and its enclosed types have a logical relationship and are used together
• They make our codebase more compact by reducing the number of source code files that we would’ve used if we’d declared them as top-level classes and interfaces

An example is the Map.Entry interface from the core Java API:

for (Map.Entry<String, String> entry : mapObject.entrySet()) { }

Making Map.Entry a nested interface strongly relates it to the java.util.Map interface and has saved us from creating another file inside the java.util package.

Please read the nested classes article for more details.

4. Public Methods

Public methods enable users to execute ready-made operations. An example is the public toLowerCase method in the String API:

assertEquals("alex", "ALEX".toLowerCase());

We can safely make a public method static if it doesn’t use any instance fields. The parseInt method from the Integer class is an example of a public static method:

assertEquals(1, Integer.parseInt("1"));

Constructors are usually public so that we can instantiate and initialize objects, although sometimes they might be private like in singletons.

5. Public Fields

Public fields allow changing the state of an object directly. The rule of thumb is that we shouldn’t use public fields. There are several reasons for this, as we’re about to see.

5.1. Thread-Safety

Using public visibility with non-final fields or final mutable fields is not thread-safe. We can’t control changing their references or states in different threads.

Please check our article on thread-safety to learn more about writing thread-safe code.

5.2. Taking Actions on Modifications

We have no control over a non-final public field because its reference or state can be set directly.

Instead, it’s better to hide the fields using a private modifier and use a public setter:

public class Student {

    private int age;
    
    public void setAge(int age) {
        if (age < 0 || age > 150) {
            throw new IllegalArgumentException();
        }
    
        this.age = age;
    }
}

5.3. Changing the Data Type

Public fields, mutable or immutable, are part of the client’s contract. It’s harder to change the data representation of these fields in a future release because clients may need to refactor their implementations.

By giving fields private scope and using accessors, we have the flexibility to change the internal representation while maintaining the old data type as well:

    
public class Student {

    private StudentGrade grade; //new data representation
   
    public void setGrade(int grade) {        
        this.grade = new StudentGrade(grade);
    }

    public int getGrade() {
        return this.grade.getGrade().intValue();
    }
}

The only exception for using public fields is the use of static final immutable fields to represent constants:

public static final String SLASH = "/";

6. Conclusion

In this tutorial, we saw that the public modifier is used to define an API.

Also, we described how overusing this modifier may restrict the ability to introduce improvements to our implementation.

Finally, we discussed why it’s a bad practice to use public modifiers for fields.