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

In general, Default/Package protection can be used to to make "Public" classes and variables more restricted.

You only export a few methods from your class (if you're a good programmer) by tagging them public while keeping as much as possible private.

Package protection allows you to only export a few classes from your package, keeping the rest private.

In theory it's a great idea, in practice you almost never see it.

Answer 2

I have objects that need access to one another. Within the package, they can call these protected methods,but when someone tries to access these protected methods, they are disallowed.

In my opinion this is a basic protection mechanism, and a hierarchy of protection would be a nice feature.

Answer 3

I know Java veterans of 5-10+ years who don't realize that protected implies package private acess. This alone, for me, makes package private an horrific language feature. Personally I don't think there is any justifiable reason to use package private anyway. Let's consider the use cases:

• Package private classes: use inner classes. Another poster suggested there is a (small) performance penalty for inner classes vs package private classes but, to me, that's not a good reason for bad design. Package private and inner classes I consider to be implementation details and, as such, I think it's better to "hide" them as inner classes;
• Package private data members: I can see no reason for these at all; and
• Package private methods: these are pretty much the equivalent of C++ friend methods. C++ friends had one good raison d'etre and that was to externalize operator overloading outside of the class, which allowed the first argument to be something other than the class itself. In Java, there is no such use case, which just leaves doing an end-run around encapsulation and abstraction.

Compare this to protected methods, which are entirely justifiable when designing classes for extension. I've seen cases where programmers inadvertently use protected methods in unrelated classes in the same package just because they come up on auto-completion lists.

And there is absolutely no way to prevent this.

C# has a better access system in that protected doesn't imply internal access. But I consider this--along with a mutable Date class--to be pretty huge flaws.

Answer 4

There are two good uses for package level visibility (in my experience):

1) Defining "internal" classes in a public API. Commonly you would define your interfaces and core factories as public and the "internal" implementations as package level. Then the public factories can construct the package level implementation classes and return them as instances of the public interfaces. This nicely allows users to only access the stuff they should.

The downside is that you have to have all this stuff in the same package, which almost never is a good idea for any reasonably-sized API. JSR 294/modules/Project Jigsaw in Java 7 will hopefully provide an alternative by specifying a new visibility modifier (module) that can be used to access classes within a module across packages without making them visible outside the module. You can find an example of how this would work in this article.

2) Unit testing is the other common use case. Frequently you'll see a src tree and a test tree and stuff that would otherwise be private is instead package level so that unit tests in the same (parallel) package are able to access otherwise hidden methods to check or manipulate state.

Answer 5

"I know how package level protection in java works ... and no-one seem to be using it."

What are they using?

Are they making all their classes public?

The Principle of Burden takes two forms.

The strong form states that the burden of transforming a collection of entities is a function of the number of entities transformed. The weak form states that the maximum potential burden of transforming a collection of entities is a function of the maximum potential number of entities transformed.

The International Organisation for Standardization defines encapsulation as the property that the information contained in an object is accessible only through interactions at the interfaces supported by the object.

At a higher level of abstraction, program units, too, may be encapsulated within subsystems, whereby the information contained in the subsystem is accessible only through public program units contained within the subsystem.

The burden of creating or modifying any software system is a function of the number of program units created or modified.

Program units that depend on a particular, modified program unit have a higher probability of being impacted than program units that do not depend on the modified program unit.

The maximum potential burden an modified program unit can impose is the impacting of all program units that depend on it.

Reducing the dependencies on an modified program unit therefore reduces the probability that its update will impact other program units and so reduces the maximum potential burden that that program unit can impose.

Reducing the maximum potential number of dependencies between all program units in a system therefore reduces the probability that an impact to a particular program unit will cause updates to other program units, and thus reduces the maximum potential burden of all updates.

Encapsulation theory shows how to use encapsulation to reduce the maximum potential number of dependencies between all program units.

Encapsulation theory therefore shows how to use encapsulation to mitigate the weak form of the Principle of Burden.

In Java, making a class package private is one of the key mechanisms for reducing the maximum potential number of dependencies in a system and so reducing the maximum possible burden of any software modification to that system.

Yet you mention that this is not used in the code you read.

That sounds ... odd.

Answer 6

Are you talking about package-private protection in Java? That's the protection that is in effect by default for class members. It's useful occasionally if you got classes that interact intimately in a way that requires additional information or methods to be visible.

Say you have a Sink class, and several classes can write to that. The Sink has a public method that accepts basic data-types, and a package private method that accepts raw byte arrays. You don't want to make that method public, because you consider it too low-level for its users, but you want to make your other classes (in the package of the Sink) writing to that Sink use it. So you make the method accepting the byte array package private, and classes of your package such as ByteStreamSource could use it. Now, your protection looks like this:

     User   Code using the package   User
------ | -----------------------------|----- package public Interface
       |                              |
    Sink <-   package priv. iface  -> Sources

The package private interface is orthogonal to the public interface established by the public methods. Package private'ness increases encapsulation, because it encourages you not to make public what shouldn't be public. It's similar to the friend keyword in C++ and the internal keyword in C#.