Why did Java make package access default?

Question

I'm asking this question because I believe they did it for a very good reason and that most people do not use it properly, well from my experience in industry so far anyway. But if my theory is true then I'm not sure why they included the private access modifier...?

I believe that if default access is properly used it provides enhanced testability whilst maintaining encapsulation. And it also renders the private access modifier redundant.

The default access modifier can be used to provide the same affect by using a unique package for methods that need to be hidden from the rest of the world, and it does this without compromising testability, as packages in a test folder, with the same are able to access all the default methods declared in a source folder.

I believe this is why Java uses package access as 'default'. But I'm not sure why they also included private access, I'm sure there is a valid use case...

Answer 1

I guess they had a good idea of what an average programmer would do. And by average programmer I mean one who is not really good at programming, but gets the job anyway because there are not enough good ones and they are expensive.

If they made "public" access the default one, most programmers would never bother to use anything else. The result would be a lot of spaghetti code everywhere. (Because if you are technically allowed to call anything from anywhere, why ever bother to encapsulate some logic within a method?)

Making "private" the default access would only be slightly better. Most beginning programmers would simply invent (and share on their blogs) a rule of thumb that "you need to write 'public' everywhere", and then they would complain why Java is so bad that it forces them to write "public" everywhere. And they would also produce a lot of spaghetti code.

The package access is something that allows programmers to use their sloppy programming techniques while writing code within one package, but then they have to reconsider it when making more packages. It is a compromise between good business practices and the ugly reality. Like: write some spaghetti code, if you insist, but please leave the ugly mess within the package; at least create some nicer interfaces among the packages.

Probably there are other reasons, too, but I wouldn't underestimate this one.

Answer 2

Default access does not render the private access modifier redundant.

Language designers position on that is reflected in official tutorial - Controlling Access to Members of a Class and it's pretty clear (for your convenience, relevant statement in the quote made bold):

Tips on Choosing an Access Level:

If other programmers use your class, you want to ensure that errors from misuse cannot happen. Access levels can help you do this.

• Use the most restrictive access level that makes sense for a particular member. Use private unless you have a good reason not to.
• Avoid public fields except for constants. (Many of the examples in the tutorial use public fields. This may help to illustrate some points concisely, but is not recommended for production code.) Public fields tend to link you to a particular implementation and limit your flexibility in changing your code.

Your appeal to testability as justification for completely dropping private modifier is wrong, as evidenced eg by the answers in New to TDD. Should I avoid private methods now?

Of course you can have private methods, and of course you can test them.

Either there is some way to get the private method to run, in which case you can test it that way, or there is no way to get the private to run, in which case: why the heck are you trying to test it, just delete the damn thing...

---

Position of language designers on the purpose and usage of package level access is explained in another official tutorial, Creating and Using Packages and it has nothing in common with the idea of dropping private modifiers (for your convenience, relevant statement in the quote made bold):

You should bundle these classes and the interface in a package for several reasons, including the following:

• You and other programmers can easily determine that these types are related...
• You can allow types within the package to have unrestricted access to one another yet still restrict access for types outside the package...

---

_{<rant "I think I heard enough whining. Guess it's about time to say loud and clear...">}

Private methods are beneficial to unit testing.

Note below assumes that you are familiar with code coverage. If not, take a time to learn, since it's quite useful to those interested in unit testing and in testing at all.

All right, so I've got that private method and unit tests, and coverage analysis telling me that there's a gap, my private method isn't covered by tests. Now...

What do I gain from keeping it private

Since method is private, the only way to proceed is to study the code to learn how it is used through non-private API. Typically, such a study reveals that reason for the gap is that particular usage scenario is missing in tests.

    void nonPrivateMethod(boolean condition) {
        if (condition) {
            privateMethod();
        }
        // other code...
    }

    // unit tests don't invoke nonPrivateMethod(true)
    //   => privateMethod isn't covered.

^{For the sake of completeness, other (less frequent) reasons for such coverage gaps could be bugs in specification / design. I won't dive deep into these here, to keep things simple; suffice to say that if you weaken access limitation "just to make method testable", you'll miss a chance to learn that these bugs exist at all.}

Fine, to fix the gap, I add a unit test for missing scenario, repeat coverage analysis and verify that gap is gone. What do I have now? I've got as new unit test for specific usage of non-private API.

1. New test ensures that expected behavior for this usage won't change without a notice since if it changes, test will fail.

2. An outside reader may look into this test and learn how it is supposed to use and behave (here, outside reader includes my future self, since I tend to forget the code a month or two after I'm done with it).

3. New test is tolerant to refactoring (do I refactor private methods? you bet!) Whatever I do to privateMethod, I'll always want to test nonPrivateMethod(true). No matter what I do to privateMethod, there will be no need to modify test because method isn't directly invoked.

Not bad? You bet.

What do I loose from weakening access limitation

Now imagine that instead of above, I simply weaken access limitation. I skip the study of the code that uses the method and proceed straight with test that invokes my exPrivateMethod. Great? Not!

1. Do I gain a test for specific usage of non-private API mentioned above? No: there was no test for nonPrivateMethod(true) before, and there is no such test now.

2. Do outside readers get a chance to better understand usage of the class? No. "- Hey what's the purpose of the method tested here? - Forget it, it's strictly for internal use. - Oops."

3. Is it tolerant to refactoring? No way: whatever I change in exPrivateMethod, will likely break the test. Rename, merge into some other method, change arguments and test will just stop compiling. Headache? You bet!

Summing up, sticking with private method brings me a useful, reliable enhancement in unit tests. In contrast, weakening access limitations "for testability" only gives me an obscure, hard to understand piece of test code, which is additionally at permanent risk of being broken by any minor refactoring; frankly what I get looks suspiciously like technical debt.

_</rant>

Answer 3

The likeliest reason is: it has to do with history. Java's ancestor, Oak, only had three access levels: private, protected, public.

Except that private in Oak was the equivalent of package private in Java. You can read section 4.10 of Oak's Language Specification (emphasis mine):

By default all variables and methods in a class (including constructors) are private. Private variables and methods can be accessed only by methods declared in the class, and not by its subclasses or any other classes (except for classes in the same package).

So to your point, the private access, as known in Java, was not there originally. But when you have more than a few classes in a package, not having private as we know it now would lead to a nightmare of name collision (for example, java.until.concurrent has close to 60 classes), which is probably why they introduced it.

However the default package access (originally called private) semantics were not changed between Oak and Java.

Answer 4

I believe that if default access is properly used it provides enhanced testability whilst maintaining encapsulation. And it also renders the private access modifier redundant.

There are situations where one would want two separate classes that are more tightly bound than exposing everything with public. This has similar ideas of 'friends' in C++ where another class that is declared as a 'friend' of another can access their private members.

If you look into the innards of classes such as BigInteger you will find a number of package default protection on fields and methods (everything that is blue triangle in the list). This allows other classes in the java.math package to have more optimal access to their innards for specific operations (you can find these methods called in BigDecimal - BigDecimal is backed by a BigInteger and saves reimplementing BigInteger again. That these are package level isn't an issue for protection because java.math is a sealed package and no other classes can be added to it.

On the other hand, there are many things that are indeed private, as they should be. Most packages aren't sealed. Without private, your co-worker could put another class in that package and access the (no longer) private field and break encapsulation.

Of note, unit testing wasn't something that was thought of back when the protection scopes were being constructed. JUnit (the XUnit testing framework for Java) wasn't conceived of until 1997 (one telling of the story of that can be read at http://www.martinfowler.com/bliki/Xunit.html ). The Alpha and Beta versions of the JDK were in 1995 and JDK 1.0 was in 1996, though the protection levels didn't really get nailed down until JDK 1.0.2 (prior to that you could have a private protected protection level).

Some would argue that the default shouldn't be package level, but private. Others argue that there shouldn't be a default protection but everything should be explicitly stated - some followers of this will write code such as:

public class Foo {
    /* package */ int bar = 42;
    ...
}

Note the comment there.

The real reason why the package level protection is the default is likely lost to the design notes of Java (I've been digging and can't find any why articles, lots of people explaining the difference, but none saying "this is the reason").

So I'll take a guess. And that's all it is - a guess.

First off, people were still trying to figure out language design. Languages since then have learned from Java's mistakes and successes. This could be listed as a mistake not to have something that needs to be defined for all fields.

• The designers saw an occasional need for a 'friend' relationship of C++.
• The designers wanted explicit statements for public, and private as these have the biggest impacts on access.

Thus, private isn't default and well, everything else fell into place. The default scope was left as default. It may have been the first scope that was created and in the interest of rigorous backwards compatibility with older code, was left that way.

As I said, these are all a guess.

Answer 5

Here is the answer as per James Gosling (inventor of Java), from an interview given here in 2000. (Hat tip to the answer here on SO.) I must say that I found this response surprising.

Java's Access Modifiers

Bill Venners: Java has four access levels. The default is package. I have always wondered if making package access default was convenient because the three keywords that people from C++ already knew about were private, protected, and public. Or if you had some particular reason that you felt package access should be the default.

James Gosling: A package is generally a set of things that are kind of written together. So generically I could have done one of two things. One was force you always to put in a keyword that gives you the domain. Or I could have had a default value. And then the question is, what makes a sensible default? And I tend to go for what is the least dangerous thing.

So public would have been a really bad thing to make the default. Private would probably have been a bad thing to make a default, if only because people actually don't write private methods that often. And same thing with protected. And in looking at a bunch of code that I had, I decided that the most common thing that was reasonably safe was in the package. And C++ didn't have a keyword for that, because they didn't have a notion of packages.

But I liked it rather than the friends notion, because with friends you kind of have to enumerate who all of your friends are, and so if you add a new class to a package, then you generally end up having to go to all of the classes in that package and update their friends, which I had always found to be a complete pain in the butt.

But the friends list itself causes sort of a versioning problem. And so there was this notion of a friendly class. And the nice thing that I was making that the default -- I'll solve the problem so what should the keyword be?

For a while there actually was a friendly keyword. But because all the others start with "P," it was "phriendly" with a "PH." But that was only in there for maybe a day.

Bill Venners: Well, I think one consequence of having package access be the default is that a lot of data ends up package access. I myself like to make data private, but I sometimes forget to type "private" so the data ends up package access.

James Gosling: Yeah, and it sort of gets into another thing -- one of the things that I had wanted to do early on was formalize setting and getting something in the language. You know how in JavaBeans there's this sort of convention that you write setter and getter methods? But I did a bunch of surveys of developers at the time, about whether or not they would like this to be there. And the average person went, "Oh my God!"

And so I didn't do it. But I think in retrospect, I should never have listened to them. I should have just done it. Because, I mean Beans basically layered on this facility that I had wanted to do anyway, but Beans did it as kind of an afterthought.

And because it's layered on as a naming convention, there's some things that don't fit together real well. And so, for instance, it would've made a lot of sense for the default protection for an instance variable to be private. And then the getters and setters, which the system would've known about at a much deeper level, to make them either public or package.

In summary (unless I am misreading Gosling's comments): This was done at an early stage when the idea of getter/setter methods for every instance variable was just beginning to be floated, was considered onerous by programmers at the time, and default package access provided a way of giving access to those variables to closely-related classes, without making the data fully public to the world. Also he claims that "people actually don't write private methods that often", which seems like a rather startling perspective. In the end he seems to regret the choice, saying, "I should never have listened to them. I should have just done it... it would've made a lot of sense for the default protection for an instance variable to be private".

Answer 6

Encapsulation is a way of saying "you don't have to think about this".

                 Access Levels
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

Putting these into nontechnical terms.

1. Public: everyone has to think about it.
2. Protected: default and subclasses have to know about it.
3. Default, if you're working on the package, you'll know about it (it's right there in front of your eyes) might as well let you take advatage of it.
4. Private, you only need to know about this if you are working on this class.

Answer 7

I don't think they focused on testing, simply because testing wasn't very common back then.

What i do think they wanted to achieve was encapsulation on the package level. A class can as you know have internal methods and fields and only expose some of it through public members. In the same way a package can have internal classes, methods and fields, and only expose some of it. If you think this way, a package has an internal implementation in a set of classes, methods and fields, along with a public interface in another (possibly partially overlapping) set of classes, methods and fields.

The most experienced coders I know think this way. They take encapsulation and apply it to an abstraction level higher than the class: a package, or a component if you like. Seems reasonable to me that the designers of Java were already this mature in their designs, considering how well Java still holds up.