Why does the “protected” modifier in Java allow access to other classes in same package?

Question

What is the reason that in Java, a member with a "protected" modifier can not only be accessed by the same class and by subclasses, but also by everyone in the same package?

I am wondering about language design reasons, not actual applications (e.g., testing)

Answer 1

This design is based on the idea that the package is the appropriate unit, maintained and released by one internally consistent team; inheritance relationships have much less to do with who's maintaining and releasing what when.

Answer 2

The modifiers are well-described at http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html. From there we see this figure.

Modifier        Class     Package   Subclass  World
public          Y         Y         Y         Y
protected       Y         Y         Y         N
no modifier     Y         Y         N         N
private         Y         N         N         N

From this the reason for the design decision is obvious: it's to have a nice symmetric matrix.

Answer 3

In Java 1.0 there was a fifth access modifier: private protected. This was protected without the default access. Apparently it never actually worked properly and was dropped in 1.1. So it looks like claims the protected is defined the way it is for total ordering appear to be spurious. (Edit: It does appear that at least one of the reasons the fifth access modifier was removed in 1.1 was that the lack of total ordering interfered with the overload selection rules.) The module access modifier in Java 7 has a few design questions in this area.

Given that it was thought that it would be a good idea for the default access modifier for members to be "package private", it seems reasonable that protected should have be at least this level of access. For my money, protected doesn't pay its way in the language at all.

Answer 4

Basically it has to do with the view of a package as an api controlled unit (hence the recommendation to start your package with your domain name - guaranteed global uniqueness), so visibility grows from private -> package-private -> protected -> public. If protected weren't an increase over package-private, rather a different type of visibility, there would have to be some way to combine the two types of visibility when needed.

Answer 5

Given progressive levels of access, private, package, protected and public, it would be unnecessarily limiting if it went protected then package since that would force me to allow subclasses access in order to grant other members of the same package. Yet, intuitively, it should be that other classes in the same package are more trustworthy than other classes "out there". So protected is between package and public in that it allows a wider exposure of access.

I think the basic reason relies on the intuition that there's a basic level of "trust" between classes in the same package; you can reasonably expect them to do the right thing with each other - in most cases the package will be the responsibility of a single engineer or team so there should be a consistent harmony of design.

Answer 6

Java does follow its design principles on itself. What happens when you try to reduce/narrow the scope of public method in a subclass ? one gets an error. Java scope modifiers levels follow : private < (default) < protected < public

All class in package are supposed to be friendly because they work together. To make a member available in package it is defined in default scope.

A subclass may reside outside the package, following scope levels again : private < (default) < protected < public - We can not narrow down the scope. Protected is broader scope than default so Java does not contradicts its own guidelines. Thus, a protected member will be available in default scope. Also : class < package < Project.

Please do not limit modifiers to only visibility, but inheritance, structure are also in work at same time and add them to picture as well. If this was true : private < protected < (default) < public. then all sub classes would have to reside in same package, then why you need to inherit you can access everything as default scope is there at applicable at package level. Default scope would have lost its value and so does inheritance.