3

When every class in Java derives from java.lang.Object then what is the purpose of having protected methods in the Object class? They will always have the same visibility as public methods.Is there any reason why the following two methods are protected in the OpenJDK implementation?

    protected native Object clone() throws CloneNotSupportedException;

    protected void finalize() throws Throwable { }

Edit: The comment stating new Object.finalize() is the best answer I could have anticipated! ..Thanks

For those who are differentiating accessibility of protected and public

  package pkg1;
   public class Parent{
    protected void fun(){}
     }

package pkg2;
public class child extends pkg1.Parent{
  void fun2()
   {  child ch=new child();
      ch.fun();   // Accesses protected method (For this class protected /public is irrelevant in terms of accessibility
      Parent p=new Parent();
      //p.fun(); //can't do this
   }
  }
rakesh99
  • 1,234
  • 19
  • 34
  • Why do you think `protected` and `public` have same visibility? If that was the case, there wouldn't be any need for both the modifiers. – Rohit Jain Mar 03 '14 at 19:06
  • 1
    Try doing `new Object().finalize();`. – Sotirios Delimanolis Mar 03 '14 at 19:08
  • possible duplicate of [Why is the finalize() method in java.lang.Object "protected"?](http://stackoverflow.com/questions/2291470/why-is-the-finalize-method-in-java-lang-object-protected) – Sotirios Delimanolis Mar 03 '14 at 19:14
  • It is definitely confusing -- the Java visibility notation is somewhat irregular, and doesn't always make 100% sense. To some extent you simply must accept it the way it is. – Hot Licks Mar 03 '14 at 19:34

3 Answers3

1

Controlling "visibility" of elements in class is important. (See language tutorial here)

As a quick summary, consider:

  1. private things are only visible to the class they are in
  2. no modifier/default are only visible to the class and the package the class is in
  3. protected things are visible to packages, class AND to sub-classes
  4. public things are visible to package, class, sub-classes AND the world
Barranka
  • 20,547
  • 13
  • 65
  • 83
ErstwhileIII
  • 4,829
  • 2
  • 23
  • 37
0

Yes it makes sanse as they will be visible for extending classes and in the same package but nowhere else. If a.B extends Object and b.C extends Object than a.B cannot call b.C#clone() method.

The same is with finalize. You can override it as it is protected, but you cannot call it from any possible context.

Antoniossss
  • 31,590
  • 6
  • 57
  • 99
0

protected methods / variables / .. are usually intended to be useful from subclasses only.

protected is also visible within the same package but that's typically not the intention since that case is already covered when leaving visibility at default (i.e. not defining one of private, protected or public).

So the typical intention of a protected method is either that subclasses can override that method to specialize the behavior or that they are being allowed to call that method (but outside classes are not - goal: encapsulation)

For example Object#finalize() does nothing per default but subclasses can (usually should not) do special cleanup operations in there when an object is garbage collected.

zapl
  • 63,179
  • 10
  • 123
  • 154