This question is raised with a clarification required to decide when to declare a method protected or public during class design of a package.My point is, if one needs to override a method of a SuperClass then make that method access level as package private or protected in SuperClass but do not give access level public, and then SubClass inherit SuperClass to override that method.if public access level method is also overridden in SubClass then public access level method has also become an implementation dependent method in every new SubClass designed, which breaks concept of abstraction. Because user using public level access method addNotify(), should know that it's implementation is different in  awt.Component/ awt.Checkbox/awt.Button class, which means hiding of implementation details not ensured here. In addition, abstract class is supposed to be discovered and designed to have only common implementations of its concrete subclass methods, But it is pretty strange to see that abstract class Component{} breaks this definition.With the access level given to this method public void addNotify() {}, Without knowing the meaning or significance of this method, I would like to ask, Does it become difficult to decide the access level of a method during class design to be either public or protected?Because I would like to say that at design time any method will be public in SuperClass only when below 2 reasons are satisfied:1) There must not be a need to override this method in SubClass in/out of package, if one tries to override SuperClass. 2) Based on the signature of any public level method it must be safe after making a decision that this method can be publicly available so that means this method should not be implementation dependent in any new SubClass  in/out of package. signature in the sense that, i made my below DList class available to perform sequential update of DList in O(n) time, so no SubClass must override prevNode() method of DList class. This is risky!!! Because prev/next pointers can be manipulated here with bad coding. LSK principle will become safe.   package DList;/* DList.java */    public class DList {    ......      public DListNode prevNode(DListNode node) { /* check this signature*/        if(node.prev != this.sentinel){            return node.prev;        }else{            return null;        }      }    .......    }    /* DListNode.java */    package List;    public class DListNode {       public Object item; /* check this */       protected DListNode prev;       protected DListNode next;      DListNode(Object i, DListNode p, DListNode n) {/* check this signature*/        this.item = i;        this.prev = p;        this.next = n;      }    }So, With the experience of java code written, it looks easy for me to decide the one of the two possible access levels of all the classes/interface design within a package.it looks easy to decide while introducing signature of new methods, whether a method should have access level privatewhether a method should have access level package privateIf i understand the below question, It would become easy to decide when a method be protected or public.1) Why java allows to override public access level methods? Because it is difficult for me to decide when to make my method protected, despite i know that public is more visible than protected among packages. One has to foresee the cost/consequence of introducing a new inheritance relation before giving protected access level to the method of your current design of class.2) Can i know the proper resource to learn when a method can be protected?Note: I am a Java beginner who currently understands abstraction/encapsulation/inheritance/polymorphism and about to learn package and access specifiers
Why public access level method get overridden in java?
java;object oriented;encapsulation;access modifiers
The answer to your last question is that it will come to you with experience. But basically, you don't start by adding new methods and then wondering which keyword to use. You start by thinking about what responsibilities the class will have, what promises it will make to the classes around it. Each class handles certain details so that other classes don't have to worry about them, and you can think of it like a bunch of contracts. The access modifiers are the tools you use to state (and to some extent enforce) those contracts.The answer to your other question is that public, protected, and private are about accessibility, not override-ability. The Java keyword that controls whether something can be overridden in a subclass is final. So if you want a member to be accessible but not  overridable, declare it public final. There is no way to do the opposite (overridable in a subclass but not accessible from a subclass) because it doesn't make sense to override something you can't see. 