3

I'd like my class to have a method that can only be called by itself or by its subclasses.

The closest thing is protected access, but it also allows other classes in the same package to call the method, which I don't want.

Is there a way to achieve this, or should I consider some sort of package refactoring instead?

It seems to me like private won't let subclasses use the method.

Voldemort
  • 17,051
  • 43
  • 135
  • 257

4 Answers4

4

See In Java, difference between default, public, protected, and private

There is no such thing. But you can move the class in an empty package and use protected.

Community
  • 1
  • 1
Markus Malkusch
  • 7,201
  • 35
  • 61
3

Short Answer: Refactor your Packages

Explanation:

The java spec considers the package relationship to be a closer relationship than that of a subclass. This is because I can extend any class as long as I import it.

If you want to be sure the method is not accessible even by subclasses outside the package, use the default visibility modifier.

Source

Stack Overflow reference

Community
  • 1
  • 1
Scott
  • 782
  • 1
  • 5
  • 14
0

To accomplish this, put your class in a package of its own and make methods default protection. There won't be any other classes in the package to see it to call it via package access.

Consider also, that if you seal the jar that the class is in, only you control what is in a given package and have effectively locked any others from creating a class in the package that you define - no one else will be able to introduce a class into the package and break the encapsulation.

  • However, "sealing" a jar file cannot prevent someone from extracting the contents of the file, adding their own class to a package, and then using the combination in their own code whether the combination is used as separate files or after bundling the files into a new jar file...possibly sealed... Not really a problem, of course, unless someone believes packages, access keywords, or "sealed" jars are making some kind of guarantee they are not. – Ned Jan 11 '14 at 06:43
  • This technique makes it impossible to subclass the class, which violates the terms of the question. -1 – user207421 Jan 11 '14 at 07:35
  • @ejp are you confusing sealing a jar with a final class? –  Jan 11 '14 at 07:51
  • @MichaelT The question is ridiculous. – user207421 Jan 11 '14 at 09:12
0

Sorry, but protected is your only choice if you want subclasses to be able to call or override a method without making it public. If you do not want other classes in the same package to have access for some reason, move your class to a new package. But if you are thinking that the package and access control keywords form some kind of DRM (i.e. digital rights management) system rather than simply a code management and class "contract" system, you are mistaken. Think of access control keywords as nothing more than documentation which the compiler has some ability to verify when other code fails to comply with the stated intent as expressed by the documentation.

Ned
  • 887
  • 6
  • 8