0

How to make a member of a class to be accessible only in subclasses in any packages? Protected is not a solution since it will open the member to other non subclasses classes.

Yaroslav
  • 1,325
  • 1
  • 11
  • 23
  • 1
    What an odd requirement. Why on earth would you want to do this? – Jokab Jun 26 '17 at 14:00
  • 1
    Also have a look at this question : https://stackoverflow.com/questions/41431533/does-java-have-a-private-protected-access-modifier – Arnaud Jun 26 '17 at 14:04
  • A similar question about the protected modifier has been asked before. I can't find it right now, but the general gist was that you should have control over the package because you're writing the program, so the package visibility shouldn't be an issue. Essentially, only the classes you choose to put in the package can access those fields and methods, so you can make them only visible to subclasses by not putting other classes in the same package. – Arc676 Jun 26 '17 at 14:04
  • 1
    @Arc676 Anyone coming later can define a class in any package. That's not normal form, but it's allowed. Just to verify, I just make a test class in `java.lang` and it compiled with no problem. – Brick Jun 26 '17 at 14:11
  • @Brick I was not aware of this option. Does this work for programs exported as JARs as well? – Arc676 Jun 26 '17 at 14:14
  • @Arc676 yes, it does. Actually it's a relatively common way to bypass encapsulation when you want to extend the behaviour of a third party lib. It's no something that you should do, because maintaining this kind of code quickly becomes a nightmare. – noscreenname Jun 26 '17 at 14:29
  • @Arc676 Yes. Packages in Java are defined only by *relative* directory structure and the `package` statement in the source file. Technically even the directory structure is not a requirement of the Java spec, but it de facto required by most implementations. – Brick Jun 26 '17 at 14:29
  • @Brick You are allowed to compile a class in java.lang, but does it also get loaded and executed? Should throw `java.lang.SecurityException: Prohibited package name: java.lang`. Sealed packages should also not allow classes from other sources... – user85421 Jun 26 '17 at 15:58

4 Answers4

1

I understand why you want to do this; however, Java simply does not provide that capability.

Steve11235
  • 2,849
  • 1
  • 17
  • 18
1

Java does not provide absolute encapsulation. Some amount of discipline is required on the part of the programmer - both the original designer and anyone that uses a published API - to abide by some rules that are outside of the language. Regarding member access, you have identified one such case. What you want is not possible in Java.

Just to put this in broader perspective, I'd point out that even private members can be accessed by other classes if a programmer is willing to go far enough to do it. Calls made via JNI do not have to respect any of the access modifiers. See, e.g., Can a native method call a private method?

Other examples of out-of-language norms include the contract for equals/hashCode, which must be met for classes to behave well with respect to collections but is not enforced at the level of the language.

Brick
  • 3,998
  • 8
  • 27
  • 47
1

You could do abstract class with protected member, and implement it in another packages. Consider you created some lib and design extensability for certain things. Later users of your lib will implement realizations of your class and has access to protected member and in same time not able to create implementation classes in your package. In example FilterReader class, it design for extensibility, after you implement it in somewhere in your code outside java.io package that protected fields and methods will be private to other classes in your package.

fxrbfg
  • 1,756
  • 1
  • 11
  • 17
0

What you are trying to achieve ist not possible during to acces control:

https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html

You may rethink your software design, since yout problem is caused by architecture. please be more specific in your question for getting further answer.

Solving your problem may cause sideeffects and is not in a OOD manner.

The only way to acces the private member is using an getter method with same visibilty issuses.

DBJamesH
  • 11