16

In Java, there are four available access modifiers for methods:

public - any class can use this method.

protected - classes in the same package and subclasses in any package can use this method.

private - only this class can use this method.

no modifier ("package private") - only classes in the same package can use this method.

What happens often is that I want to have useful methods in a superclass, that all subclasses can use. But it wouldn't make sense for other classes to access this method, and in a sense it would break encapsulation.

So I have to declare these useful methods in the superclass public or protected, which exposes them to all other classes at least in the package. Even though they're only meant to be used by the subclasses.

Is there a reason why there isn't a subclasses-only access modifier in Java? It seems very odd to me. Am I missing something?

Also, a subclasses-only access modifier would also be useful for when you want to expose variables only to subclasses. Which to me happens a lot.

10

Because you can emulate the subclasses-only modifier by using the protected modifier and enforcing that only the parent class and its subclasses are in the same package.

It's indeed a good practice, because the packages not only help to organize big projects in terms of cohesion, but they also show that the classes in the same package might have some level of coupling.

  • 15
    "and enforcing that only the parent class and its subclasses are in the same package" -- Now, how would one do that?! – JimmyB Nov 28 '14 at 14:16
  • 1
    And then you can't use the package-only access modifier. And you need a silly amount of packages. This is not a practical solution. – user253751 May 22 '18 at 23:42
12

Java originally had such a modifier. It was written private protected but removed in Java 1.0.

I assume that was a judgment call that the extra complexity wasn't worth the cost.

Every language feature has a cost: in teaching it to new programmers; in documentation; in implementing it in the compiler, JVM, and dev tools; in reasoning about program correctness; in constraining future language evolution; and more. Language features interact with each other, potentially with N2 interactions.

What percent of Java programmers have read through the Java language spec and VM spec? I bet it's a small percentage, which argues for an even simpler language for the sake of understandability and engineering products that we can depend on

The benefit of the private protected feature was small since the package is the main unit of modularity.

  • 1
    so there was a Java version before 1.0? – Mark Yisri Jan 2 '17 at 18:24
  • 1
    @MarkYisri Java had public alpha and beta releases in 1995, and a fair bit of code was written against them. – David Moles Jan 3 '17 at 19:41
4

Acess control can be thought of as the result of a coversation with an imaginary developer who is working with your class about the class methods and properies...

YOU: Say you want to do x, you call the method doX.. DEV: Tell me more..what are the arguments?

This is public...

YOU: Inside doX I call ... DEV: Whoa, too much information, I don't care about that. I just want to know how to use it. Tell me something else.

This is private...

YOU: When subclassing, I have doX and doY call doIt which does.. DEV: Yeah, I gonna subclass, tell me more...

This is protected...

YOU: I'm leaving on on vacation in an hour, I'll be gone for the next 6 months. The Boss says this puppy is yours! Bye. DEV: Wait don't go yet, tell me everything...

This is package.

YOU: The method doItWhen is only called by this class and it hasn't changed in ten years. It... DEV: Whoa, we're down to 50 minutes. Next property, and talk faster.

This is protected private...

3

This already exists. It is protected.

You have control over what classes exist within the package. If there is no other class in the package and a given variable or method is protected, it is 'subclasses only'.

That said, once again, you have control over what classes exist within the package. You can chose to just not use the protected methods or variables.

  • 3
    Apart from certain reserved system packages, can't I add a class to any package, even one of yours that you don't intend me to add classes to? – David Moles Oct 5 '15 at 17:35
  • @David IIRC yes, but it won't let you access package fields from another JAR so even if you put it in the same package, if it's in another JAR you can't access it. However, if you're referring to within the same JAR, then yes, you can access it, but if you're able to modify the JAR in question you could just as easily change the access modifier. – Pokechu22 Jan 3 '17 at 15:26
  • 1
    @Pokechu22 I think you have to affirmatively seal the JAR to get that protection, but good point. – David Moles Jan 3 '17 at 19:36

protected by gnat Jan 3 '17 at 17:07

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.