There is a library, in it, for example, there is such a class:

public class SimpleObject { private object; public void setObject(Object object) { ... } public Object getObject() { ... } }

Nearby, in a nearby package, is the ObjectHandler class, which accepts this object and, based on the result of the .getObject() method, does something.

It is necessary to make the user, having received or created a SimpleObject object, could not use the .getObject() method (so that the method for the user was something like private ), and the ObjectHandler class could see it.

How to do it?

This is necessary in order not to show the user unnecessary methods (and it is more convenient for him and safer for me). Now, to achieve this goal, we have to throw an object and its handler into one package (which looks a bit incomprehensible), and make the get method available within the package.

  • So you need the method to be available in one package (not the same one), but not available in another package? - Regent
  • Do you want to protect yourself from accidental use? or from any use? - Mikhail Vaysman
  • @Regent, well .. You could say that. - Rostislav Dugin
  • @MikhailVaysman, anyone. - Rostislav Dugin
  • @Regent, there is a project package, and there is a bunch of subpackages. Here it is necessary that the method of one subpackage be visible in other subpackages, but not visible to anyone who is not in the project package. - Rostislav Dugin

2 answers 2

In Java, it is impossible "somewhere to the side" from protected or public (as well as at the beginning of the file) to specify packages in which the method will be available. The documentation says only under which modifiers there is access within the package, and under which - "all over the world."
There is also no such thing as a "sub-package". There is a good answer to enSO on this.

It turns out that using access modifiers does not achieve the desired result. In this case, there are such options:

  1. Leave SimpleObject and ObjectHandler in one package if this is justified or other options are not appropriate.
  2. Reconsider class architecture. For example, it is possible that instead of ObjectHandler you can use a superclass for SimpleObject that contains the necessary functionality.

Suppose the SimpleObject class looks like this:

 package test2; public class SimpleObject { private Object object; public void setObject(Object object) { this.object = object; } protected Object getObject() { return object; } }

"Kostyl" solutions:

  1. In the package that contains the ObjectHandler , create the class MySimpleObject extends SimpleObject and override the necessary methods in it:

     package test3; import test2.SimpleObject; public class MySimpleObject extends SimpleObject { protected Object getObject() { return super.getObject(); } }

    Then use MySimpleObject instead of SimpleObject :

     MySimpleObject mso = new MySimpleObject(); mso.setObject("Str"); System.out.println(mso.getObject());

  2. “Breaking Bad” and gaining access to the method through reflection:

     SimpleObject so = new SimpleObject(); so.setObject("Str"); try { Method method = so.getClass().getDeclaredMethod("getObject"); method.setAccessible(true); System.out.println(method.invoke(so)); } catch (Exception e) { }
  • Eh ... Everything is as I thought (but, to be honest, you came up with more crutch solutions, I wouldn’t even think about reflection :)). But I still came up with solutions (as part of the project, not a question): I’ll make a Builder with get methods visible within the project, and then create an object with logic. Well .... Maybe it doesn't sound very clear, then I will show the project :). - Rostislav Dugin

From the "stupid" "users" can not be protected. If your SimpleObject is an entity level ( @Entity ), then all its getters & setters must be public . This is correct and logical. And there is nothing wrong with someone creating and fully using your SimpleObject entity.

But, if SimpleObject is a kind of API method, then you really need to .getObject() protect it from the “user”, that is, to control the protection against receiving an incorrect value or calling .getObject() at the wrong time according to the logic of your project.

In such a case, I recommend leaving the visibility modifier public getObject() , but to protect against improper use through Exception .

Create your Exception or use the existing one. For example:

 public class MyLogicalException extends Exception { public MyLogicalException(String message) { super(message); } }

And declare that the getObject() method can throw a MyLogicalException exception under certain circumstances. For example:

 public Object getObject() throws MyLogicalException { if (object == null) { throw new MyLogicalException("object не может быть пустым!"); } else { return object; } }
  • Hmm, a really interesting option! It is also possible (if necessary for all methods) to perform an interceptor check. - Rostislav Dugin