What is the difference between public, protected, package-private, and private in Java? [Answered]


In Java, are there clear rules on when to use each of access modifiers, namely the default (package private), publicprotected and private, while making class and interface and dealing with inheritance?

What is the difference between public, protected, package-private, and private in Java? Answer #1:

The official tutorial may be of some use to you.

(same pkg)
(diff pkg)
no modifier+++

+ : accessible
blank : not accessible

Answer #2:

(Caveat: I am not a Java programmer, I am a Perl programmer. Perl has no formal protections which is perhaps why I understand the problem so well 🙂 )


Like you’d think, only the class in which it is declared can see it.

Package Private

It can only be seen and used by the package in which it was declared. This is the default in Java (which some see as a mistake).


Package Private + can be seen by subclasses or package members.


Everyone can see it.


Visible outside the code I control. (While not Java syntax, it is important for this discussion).

C++ defines an additional level called “friend” and the less you know about that the better.

When should you use what? The whole idea is encapsulation to hide information. As much as possible you want to hide the detail of how something is done from your users. Why? Because then you can change them later and not break anybody’s code. This lets you optimize, refactor, redesign, and fix bugs without worrying that someone was using that code you just overhauled.

So, the rule of thumb is to make things only as visible as they have to be. Start with private and only add more visibility as needed. Only make public that which is absolutely necessary for the user to know, every detail you make public cramps your ability to redesign the system.

If you want users to be able to customize behaviors, rather than making internals public so they can override them, it’s often a better idea to shove those guts into an object and make that interface public. That way they can simply plug in a new object. For example, if you were writing a CD player and wanted the “go find info about this CD” bit customizable, rather than make those methods public you’d put all that functionality into its own object and make just your object getter/setter public. In this way being stingy about exposing your guts encourages good composition and separation of concerns

Personally, I stick with just “private” and “public”. Many OO languages just have that. “Protected” can be handy, but it’s really a cheat. Once an interface is more than private it’s outside of your control and you have to go looking in other people’s code to find uses.

This is where the idea of “published” comes in. Changing an interface (refactoring it) requires that you find all the code which is using it and change that, too. If the interface is private, well no problem. If it’s protected you have to go find all your subclasses. If it’s public you have to go find all the code which uses your code. Sometimes this is possible, for example, if you’re working on corporate code that’s for internal use only it doesn’t matter if an interface is public. You can grab all the code out of the corporate repository. But if an interface is “published”, if there is code using it outside your control, then you’re hosed. You must support that interface or risk breaking code. Even protected interfaces can be considered published (which is why I don’t bother with protected).

Many languages find the hierarchical nature of public/protected/private to be too limiting and not in line with reality. To that end, there is the concept of a trait class, but that’s another show.

Answer #3:

Here’s a better version of the table, that also includes a column for modules.

Java Access Modifiers


  • private member (i) is only accessible within the same class as it is declared.
  • A member with no access modifier (j) is only accessible within classes in the same package.
  • protected member (k) is accessible within all classes in the same package and within subclasses in other packages.
  • public member (l) is accessible to all classes (unless it resides in a module that does not export the package it is declared in).

Which modifier to choose?

Access modifiers are a tool to help you to prevent accidentally breaking encapsulation(*). Ask yourself if you intend the member to be something that’s internal to the class, package, class hierarchy or not internal at all, and choose access level accordingly.


  • A field long internalCounter should probably be private since it’s mutable and an implementation detail.
  • A class that should only be instantiated in a factory class (in the same package) should have a package restricted constructor, since it shouldn’t be possible to call it directly from outside the package.
  • An internal void beforeRender() method called right before rendering and used as a hook in subclasses should be protected.
  • void saveGame(File dst) method which is called from the GUI code should be public.

Answer #4:

                | highest precedence <---------> lowest precedence
 \ xCanBeSeenBy | this          | any class | this subclass | any
  \__________   | class         | in same   | in another    | class
             \  | nonsubbed     | package   | package       |    
Modifier of x \ |               |           |               |       
public          |       ✔       |     ✔     |       ✔       |   ✔  
protected       |       ✔       |     ✔     |       ✔       |   ✘   
package-private |               |           |               |
(no modifier)   |       ✔       |     ✔     |       ✘       |   ✘   
private         |       ✔       |     ✘     |       ✘       |   ✘    

Answer #5:

Easy rule. Start with declaring everything private. And then progress towards the public as the needs arise and design warrants it.

When exposing members ask yourself if you are exposing representation choices or abstraction choices. The first is something you want to avoid as it will introduce too many dependencies on the actual representation rather than on its observable behavior.

As a general rule I try to avoid overriding method implementations by subclassing; it’s too easy to screw up the logic. Declare abstract protected methods if you intend for it to be overridden.

Also, use the @Override annotation when overriding to keep things from breaking when you refactor.

Answer #6:

It’s actually a bit more complicated than a simple grid shows. The grid tells you whether an access is allowed, but what exactly constitutes an access? Also, access levels interact with nested classes and inheritance in complex ways.

The “default” access (specified by the absence of a keyword) is also called package-private. Exception: in an interface, no modifier means public access; modifiers other than public are forbidden. Enum constants are always public.


Is an access to a member with this access specifier allowed?

  • Member is private: Only if member is defined within the same class as calling code.
  • Member is package private: Only if the calling code is within the member’s immediately enclosing package.
  • Member is protected: Same package, or if member is defined in a superclass of the class containing the calling code.
  • Member is public: Yes.

What access specifiers apply to

Local variables and formal parameters cannot take access specifiers. Since they are inherently inaccessible to the outside according to scoping rules, they are effectively private.

For classes in the top scope, only public and package-private are permitted. This design choice is presumably because protected and private would be redundant at the package level (there is no inheritance of packages).

All the access specifiers are possible on class members (constructors, methods and static member functions, nested classes).


The access specifiers can be strictly ordered

public > protected > package-private > private

meaning that public provides the most access, private the least. Any reference possible on a private member is also valid for a package-private member; any reference to a package-private member is valid on a protected member, and so on. (Giving access to protected members to other classes in the same package was considered a mistake.)


  • A class’s methods are allowed to access private members of other objects of the same class. More precisely, a method of class C can access private members of C on objects of any subclass of C. Java doesn’t support restricting access by instance, only by class. (Compare with Scala, which does support it using private[this].)
  • You need access to a constructor to construct an object. Thus if all constructors are private, the class can only be constructed by code living within the class (typically static factory methods or static variable initializers). Similarly for package-private or protected constructors.
    • Only having private constructors also means that the class cannot be subclassed externally, since Java requires a subclass’s constructors to implicitly or explicitly call a superclass constructor. (It can, however, contain a nested class that subclasses it.)

Inner classes

You also have to consider nested scopes, such as inner classes. An example of the complexity is that inner classes have members, which themselves can take access modifiers. So you can have a private inner class with a public member; can the member be accessed? (See below.) The general rule is to look at scope and think recursively to see whether you can access each level.

However, this is quite complicated, and for full details, consult the Java Language Specification. (Yes, there have been compiler bugs in the past.)

For a taste of how these interact, consider this example. It is possible to “leak” private inner classes; this is usually a warning:

class Test {
    public static void main(final String ... args) {
        System.out.println(Example.leakPrivateClass()); // OK
        Example.leakPrivateClass().secretMethod(); // error

class Example {
    private static class NestedClass {
        public void secretMethod() {
    public static NestedClass leakPrivateClass() {
        return new NestedClass();

Compiler output:

Test.java:4: secretMethod() in Example.NestedClass is defined in an inaccessible class or interface
        Example.leakPrivateClass().secretMethod(); // error
1 error

Answer #7:

As a rule of thumb:

  • private: class scope.
  • default (or package-private): package scope.
  • protectedpackage scope + child (like package, but we can subclass it from different packages). The protected modifier always keeps the “parent-child” relationship.
  • public: everywhere.

As a result, if we divide access right into three rights:

  • (D)irect (invoke from a method inside the same class, or via “this” syntax).
  • (R)eference (invoke a method using a reference to the class, or via “dot” syntax).
  • (I)nheritance (via subclassing).

then we have this simple table:

|                 |    Same    | Different |
|                 |   Package  | Packages  |
| private         |   D        |           |
| package-private |            |           |
| (no modifier)   |   D R I    |           |
| protected       |   D R I    |       I   |
| public          |   D R I    |    R  I   |

Hope you learned something from this post.

Follow Programming Articles for more!

About ᴾᴿᴼᵍʳᵃᵐᵐᵉʳ

Linux and Python enthusiast, in love with open source since 2014, Writer at programming-articles.com, India.

View all posts by ᴾᴿᴼᵍʳᵃᵐᵐᵉʳ →