I want to understand, from design point of view, in what situations I should use default access modifier, and when I shouldn't.

I found this related question, that provides some basic explanations, how ever I am searching for an answer that will target encapsulation and single reason of change principles, and address it in more professional way.


3 Answers 3


The default access is otherwise known as package level private or protected... your choice, it doesn't really have a term, but its useful to think of it that way.

If you dig within the source for java.lang you will often see it - allowing other classes within java lang to be able to access some of the internals of this class without exposing those internals to all of the world.

Just glancing, an example of this is the sizeTable within java.lang.Integer (grepcode) that allows there to be a single point where this information is stored. As this is associated with stringSize (just below it) that is likely used within java.lang.String it means that one doesn't have to have two copies of it or expose it. Other methods in the area also show more of this Integer/String relationship.

Thinking about this more, you've got Integer.toString(int i) and String.valueOf(int i) - both of which do very similar things. While its debatable if you want to have the ability to do the same thing in two classes... if you do, you only want to have the code in one place - which again points you to having a package level encapsulation.

Putting things within the same package is supposed to be an important part of encapsulation. The classes within a package are supposed to work closely with each other. It means these classes should be able to look at each other's internals and work with them. It avoids having java.lang.FunkyStringConstatns sitting out there for all the world to see... and once the world sees it as something public, it means that one can't go and change it.

This has less meaning when one works on the entire project from start to finish and there is no public API. Its more a 'yea, its there' then. But if you are working on public APIs, you will want times to be able to share data without sharing it with the world.

  • How do you see the "single reason of change" principle feels in to "package encapsulation"? Jul 7, 2014 at 16:28
  • If Java was to change to have its ints be a 64 bit int, there is a bit code that would need to change around the 'convert this value to a string or string to an int'. The only two classes that need to deal with that are java.lang.Integer and java.lang.String. That is good encapsulation. As they are both within the java.lang package, all the changes for this would be made in one place - the java.lang.Integer class - without causing problems with the public API.
    – user40980
    Jul 7, 2014 at 16:32
  • A nitpick: default access != protected. It's true that it's often called "package access" though. I've even seen declarations like this one: /* package */ String field;
    – mkalkov
    Jul 8, 2014 at 12:29

The default access modifier makes the member visible throughout the entire package. This makes using it on a member that's mutable in any way only marginally better than a global variable. The only possible use I can think of for it is to create constants that you can use as an implementation detail within a package. If you later decide to get rid of or change the constants, no code outside that package will break.


Your question is generic, so the answer is when it helps. However, I can name two cases where I find myself using default modifiers often.

Firstly, they are handy when you want to test a private method but don't want to make it available for child classes or outside of package.

Another use case is to refactor a nested class into a separate file while keeping private parent class members accessible for it.

UPDATE: I'm aware that my examples go against best practice (test interface, not implementation), but I believe these shortcuts are acceptable when under pressure to deliver quickly and the code base is of moderate size.

Not the answer you're looking for? Browse other questions tagged or ask your own question.