Package and Visibility

I am making an SDK and I am trying to separate classes into different packages, these classes use some other common classes. The problem is that if I made the common classes public, everyone could see them, not just my classes. What is the right way to make them available only to my application?

Example:


Package a MyClass1

Package b MyClass2

Package c public MySharedClass


Since c is publicly accessible, MySharedClass will be able to access it, but the problem is that it will also be visible to the whole world, how can I prevent this?

+4
source share
5 answers

All packages are "publicly available" in Java, which you can protect, these are classes inside the package. To limit the class’s visibility only for a given package, declare it like this (without the public visibility public ):

 class MyClass { // ... } 

Thus, only classes in the same package as MyClass can see.

+3
source

Create a package that is documented as an internal package that will not be used by clients.

In Java, there is no way to make a class publicly available only for specific packages: it is either public for everyone, or for private-package (public only in the declared package).

I think there is a suggestion for modules that allow better control over the visibility of classes, but we will have to wait, at least for Java 8.

+3
source

Nontrivial:

Generic classes can be defined by a public set of interfaces. The actual implementation must be loaded explicitly through Classloader . After that, simply apply the Java security management mechanisms to control access to the implementation classes. Anyone can see that the interfaces and access to the actual implementation will be limited by your SDK.

(The importance of the above is what every web application server should do. Do you think that Tomcat prevents you from accessing other "public" application classes?)

edit: the note above is the execution mechanism. There are also static (post) compilation approaches. For example, APT may be effective. Naturally, I am not referring to the restructuring of your package (in the OP) and only to how to provide access to the general approach. But they are a bit “hacked” - the mechanism for loading classes is canonical, and imo is more correct.

+3
source

If a class is separated by classes from two different packages, this can be a good indicator that these two classes should be in the same package together with a common class that will not be publicly available and, therefore, will be used only for use on classes of the same package .

If this is really not an option, simply document the generic class appropriately to indicate that it should not be used outside the SDK's internal code, so that it undergoes changes in future versions and makes it even clearer, calling the package “internal” or something like of this.

+1
source
Protected Modifier

can use if your class will have access only in the same package. otherwise there is no possibility.

+1
source

Source: https://habr.com/ru/post/1388177/


All Articles