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

Another use of default protection in Java is for performance.

Inner classes are allowed to access private members of their containing class, but this is implemented through obfuscated accessor methods. Before the JIT compiler optimizes this away (or in environments without a JIT such as J2ME) this causes a small performance hit. Declaring the needed methods with default protection eliminates the need for these accessor method calls, but doesn't require making the members fully public.

Keep in mind that this is only important where performance is known to be critical, and where you can't count on the JVM fixing the issue for you. But at least it doesn't really harm readability/maintainability as much as many other micro-optimizations.

Answer 2

Mostly for Unit testing where source and test files are in the same package, tests can access the internals of the class without exposing it.

Answer 3

Nowadays, packages are often used to model "software components", i.e. a package is a group of classes somehow related. Since "public" methods define the external interface of a software component, and "private" methods/members are implementation details of a class, the default "package" visibility amounts to component-internal methods.

An analogy might be "friend" methods in C++.

Answer 4

I think that in principle package level protection makes a lot of sense. It allows you to create something close to a module (a package) but only expose the core classes.

For example, many of my projects work with public interfaces and "hidden" classes that implement them. Users use factories, and receive a reference to the interface which corresponds to a "hidden" concrete implementation. With package protection I should be, in theory, able to only expose the interfaces and the factory.

Unfortunately, because package protection does not apply to subpackages, it doesn't really fit the way that I work. I like using other packages and in particular subpackages for my "internal" stuff (in the same way that Eclipse is organized). As a result, my package cannot access package-level protected things in the subpackage. I do wish that this would be changed one day.

Answer 5

The reason why nobody uses package level access it is probably a psychological effect. Every java introduction preaches encapsulation, which is understood as declaring all fields private. Private access is very often too narrow, so a public getter/setter must be added. This pattern is then repeated throughout the whole codebase: private fields and public methods everywhere. Ironically, the pattern subverts encapsulation, as the whole implementation is essentially nailed down by the getter/setter pairs.

A class is primarily the unit of memory allocation and in many cases that is just too small to provide a meaningful interface to the rest of the program. It is a much better idea to use packages as the unit of encapsulation and focus on giving them well defined public interfaces.

Superpackages in 1.7 might change the rules of the game.

Answer 6

In my opinion, package-private (default) access for methods and fields is useless. In fact, it's worse than useless, it's harmful since it's typically used to provide access to some member that ought to be private but isn't for reasons of convenience.

However, package-private classes are useful. You may want to provide an implementation of an interface using a package-private class. A factory method might be declared to return an object that implements a given interface. In this situation, it is not important to know which class is providing the implementation for the interface. By making the class package-private, it is not part of the public API and therefore can be modified or replaced in future versions.

In Oak, the language that later became Java, there were only 3 access levels.

If I were redesigning Java now, I would get rid of the current default (package-private) and make private the default. A private class would be one that is private within its enclosing scope (the package), which would work exactly how package-private classes work already and be more consistent with the use of 'private' for members.