What is the use of package level protection in java?

Question

I know how package level protection in java works. I read a lot of code (including lots of open source stuff) and no-one seem to be using it. The whole protection l

Answer 1

It can be used for implementation classes, for one thing. For example, EnumSet is an abstract class, and no implementing classes are shown in the docs. Why? Because there are two implementing classes--one for enums with 64 or fewer elements, and one for 65 or more--and you don't really need to know which one you're using. In fact, you don't even need to know that there's more than one implementation. In fact, you don't even need to know that EnumSet is abstract--you just need to know that you can call one of the static methods and get a Set back.

In this case, private internal classes might have sufficed (although unwieldy, especially for large classes). But sometimes other classes in a package would need access to such implementation details. protected could work, but then they would be open to subclasses also.

In short, it covers an area of encapsulation that is not handled by the other three levels of protection.

Answer 2

Default protexction, ie "package" protection means it's private to the package, but can "see" anything that's not private to a class in the package. One use is for helper classes for the package; say you have a class that manages a pooled resource you don't want to make visible, you could put it in a default-protection class. Now it can be used by everything in the package, and it can access any protected internals of the other classes, but it's not part of the visible package to a user.

Answer 3

I am debating many of these issues in my mind currently and this is a good discussion. I have been opting to make all private things private the way they should be, but then I am writing a ton of reflection to unit test privately scoped code. This is, I think the pure OO way to do it. However, I have discovered that it is possible to seal a jar file so that package scope is restricted to inside the module (jar). This, in my mind makes package scope much more palatable. I may be willing to break good encapsulation in exchange for reducing my unit test code to a fraction of what it would be. The thought being that if someone were working in the same library and in the same package that they would be intimate enough with the code base to not access package scope members from outside the class without a reasonable design debate. It is still a tough call. It would be nice to have a friend class type of designation for this type of instance so that my unit test code code access my private code, but not be accessed by other classes. I have just sealed my jar files in this project through maven:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <version>2.3.2</version>
            <configuration>
                <archive>
                    <index>true</index>
                    <manifest>
                        <addClasspath>true</addClasspath>
                    </manifest>
                    <manifestEntries>
                        <sealed>true</sealed>
                    </manifestEntries>
                </archive>
            </configuration>
        </plugin>

Now I am debating about pulling out a bunch of reflection code in my unit tests.

I am still on the edge of the debate. Package scope is really quite open, especially if you have many developers bouncing around the code base.