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

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)

Solution 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.

Solution 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.

Solution 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.

Solution 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.

Solution 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.