When to package-private (no explicit modifier) in

Question

I have been reading the tutorial Controlling Access to Members of a Class. I am confused what might be good use case for using package-private. Because as I understand, you can always change your package declaration to whatever the package declaration of such a class and act as if that is a public class. I understand that this is not a good thing to do, but what is stopping me?

Answer 1

Because as I understand, you can always change your package declaration to whatever the package declaration of such a class and act as if that is a public class

Well, for one thing, the access modifiers are there to help the developer. There's always ways around them, such as via reflection for instance.

I understand that this is not a good thing to do, but what is stopping me?

Not much really!

As a developer you can however distribute your classes in sealed .jar-files which basically means that you're not letting anyone else in to your packages.

From Sealing Packages within a JAR File

Sealing Packages within a JAR File

Packages within JAR files can be optionally sealed, which means that all classes defined in that package must be archived in the same JAR file. You might want to seal a package, for example, to ensure version consistency among the classes in your software.

Answer 2

Regarding "what is stopping me":

The Java Security mechanism is stopping you, potentially. If the "target" package is sealed and signed, then Java will not allow any source other than the original to declare classes in that package.

Answer 3

A couple of reasons to use package-private classes/methods:

1. Implementation classes that are part of a library, but not part of the library's API. This allows you to still have modular code, and acts as a sign to users of the API that the implementation classes are not for use as part of the API.
2. Making things available to tests. Sometimes (particularly when working with legacy code) you need to make classes or members more visible so that you can more easily unit test them. An example might be testing a class with a method that performs a resource-intensive operation that you want to override with a no-op version in your test. Another example is a class that only gets used in one place: it doesn't want to be visible to the whole app, but it needs to be unit tested.

In both cases using package-priviate visibility helps to make your code easier to use (people using it have a better idea of the scope of the class/member's intended use), while allowing you to still have modular code.