Search the courses, subjects, tracks, games and features, or jump straight to a page.
Learn it your way
A short class with Sarah and her students. The other ways are under More.
Sign up free to listen. Transcripts are free to read.
We have met public and private, and the overview introduced default. Protected is the next one. Who remembers where a default member can be used?
Only by classes in the same package.
Right. Protected keeps all of that and adds one more group: subclasses, even when they sit in another package.
So inside its own package, protected is just like default?
Exactly. You only see the difference outside the package, where subclasses are let in and every other class is kept out.
Like a family recipe: everyone in the house can read it, and so can the children who move to another city, but not the neighbours there.
A lovely picture. Protected equals default plus subclasses.
ArrayList lives in java.util, and its method removeRange is protected. Can our Main class call it on a list?
Main is not in java.util and is not a subclass, so no.
Correct, the compiler says 'removeRange(int,int) has protected access in ArrayList'. Now suppose we write class MarksList extends ArrayList.
Then MarksList is a subclass, so inside MarksList we can call removeRange.
Yes, through inheritance, on its own MarksList objects. If MarksList tried it on a plain ArrayList variable, it would be refused again.
So the subclass can use it on its own kind of object, not on any list in the world.
That is the fine print of protected across packages.
A parent class has protected void show(). The child wants to override it as a plain void show(). Will that compile?
No access word means default, and default is narrower than protected.
Right, the compiler complains about 'weaker access privileges'. An override may keep protected or make it public, never narrower.
Then why not just make everything public?
Because public promises the whole world that the member will always be there. Protected promises it only to the package and to subclasses.
So protected is for the parts that children of the class need, but strangers do not.
Exactly, and fields are usually still best kept private.
Open to the same package and to subclasses in any package, closed to other classes elsewhere.
Inside the package they behave the same; only subclasses outside the package tell them apart.
Outside its package, a subclass uses a protected member through this, super or its own type, not a parent-type variable.
Only members and nested classes can be protected.
An override of a protected method may stay protected or become public, but never narrower.
Subclasses use protected fields of their parent directly to work out different salaries:
class Employee {
protected String name;
protected double basicPay;
Employee(String name, double basicPay) {
this.name = name;
this.basicPay = basicPay;
}
}
class Manager extends Employee {
Manager(String name, double basicPay) {
super(name, basicPay);
}
double salary() {
return basicPay + basicPay * 0.20; // 20% bonus on the protected basicPay
}
}
class Clerk extends Employee {
Clerk(String name, double basicPay) {
super(name, basicPay);
}
double salary() {
return basicPay + 2500; // fixed allowance
}
}
public class SalaryDemo {
public static void main(String[] args) {
Manager m = new Manager("Farah", 50000);
Clerk c = new Clerk("Gopal", 22000);
System.out.println(m.name + " earns " + m.salary());
System.out.println(c.name + " earns " + c.salary());
}
}An override may widen a protected method to public, but may not narrow it:
class Shape {
protected String name;
Shape(String name) {
this.name = name;
}
protected double area() {
return 0;
}
}
class Circle extends Shape {
private double r;
Circle(double r) {
super("Circle");
this.r = r;
}
public double area() { // widened from protected to public: allowed
return Math.PI * r * r;
}
}
class Square extends Shape {
private double side;
Square(double side) {
super("Square");
this.side = side;
}
protected double area() { // kept protected: allowed
return side * side;
}
}
public class AreaDemo {
public static void main(String[] args) {
Shape[] shapes = {new Circle(7), new Square(5)};
for (int i = 0; i < shapes.length; i++) {
double rounded = Math.round(shapes[i].area() * 100) / 100.0;
System.out.println(shapes[i].name + " area = " + rounded);
}
}
}In a game library, a class Character in package game.core has a protected method takeDamage(); a class Wizard in package game.heroes that extends Character may call takeDamage() inside its own methods, but a class Scoreboard in package game.ui, which is not a subclass, may not.
Package friends and children too, protected lets them both get through.
A family recipe book stays at home where the whole household can read it. The children who move abroad take the recipes with them, but their new neighbours never see the book.
P plus S: Protected means Package plus Subclasses.
S.P.I. - Same class, same Package, and Inheriting subclasses anywhere.
Term
Who can use a protected member?
Click to flip
Term
Protected compared with default
Click to flip
Term
Can a top-level class be protected?
Click to flip
Term
Overriding a protected method
Click to flip
Term
A subclass in another package and a parent-type variable
Click to flip
The access level that opens a member to its own package and to subclasses in any package.
A class that extends another class and inherits its public and protected members, and its default members too if it is in the same package.
The class that a subclass extends, also called the parent or base class.
The mechanism by which a subclass receives the fields and methods of its superclass.
A named group of related classes, such as java.util, that also forms an access boundary.
Giving a subclass its own version of an inherited method with the same name and parameters.
A narrower access level, such as default compared with protected; an override may not use one.
A protected member can be used by every class in its own package and, outside that package, by subclasses that inherit it; protected is the access level designed for inheritance.
This lesson explains the protected access modifier: exactly which classes can use a protected field, method or constructor; how protected differs from default (package-private) access; the extra rule that a subclass in another package may use an inherited protected member only through its own objects; and why a top-level class can never be protected. Complete programs, including one that uses a protected method of Java's own ArrayList class from the java.util package, show each rule working.
The protected keyword sits between default and public. A protected member is open to two groups of classes besides its own: every class in the same package, and every subclass, even one in a different package. Everyone else is shut out.
A simple way to remember it: protected = default + subclasses. Inside its own package, protected behaves exactly like default access. The difference shows only outside the package, where subclasses get in and other classes do not.
Fields, methods, constructors and nested classes can be protected. A top-level class cannot: writing protected class Shape at the top of a file gives modifier protected not allowed here, because a top-level class can only be public or have default access.
In this program all three classes are in the same package (the default one), so every class can use the protected members of Vehicle.
class Vehicle {
protected String name;
protected int speed;
protected Vehicle(String name) {
this.name = name;
}
protected void showSpeed() {
System.out.println(name + " is moving at " + speed + " km/h");
}
}
class Car extends Vehicle {
Car(String name) {
super(name);
}
void accelerate(int amount) {
speed = speed + amount; // inherited protected field
showSpeed(); // inherited protected method
}
}
public class ProtectedDemo {
public static void main(String[] args) {
Car car = new Car("Red car");
car.accelerate(40);
car.accelerate(20);
Vehicle scooter = new Vehicle("Blue scooter");
scooter.speed = 30; // allowed: same package as Vehicle
scooter.showSpeed();
}
}It prints Red car is moving at 40 km/h, Red car is moving at 60 km/h and Blue scooter is moving at 30 km/h. If ProtectedDemo were moved to a different package, the line scooter.speed = 30; would fail with speed has protected access in Vehicle, while Car, being a subclass, could still use speed through inheritance.
Java's own ArrayList class lives in the package java.util, and its method removeRange(from, to) is protected. Our classes are in a different package, so only a subclass of ArrayList may call it, and only through inheritance.
import java.util.ArrayList;
class MarksList extends ArrayList<Integer> {
// removeRange is protected in java.util.ArrayList.
// MarksList is a subclass, so it may call it through inheritance.
void dropTests(int from, int to) {
removeRange(from, to);
}
}
public class CrossPackageDemo {
public static void main(String[] args) {
MarksList marks = new MarksList();
marks.add(56);
marks.add(61);
marks.add(48);
marks.add(73);
marks.add(80);
marks.dropTests(1, 3);
System.out.println("Marks kept: " + marks);
// marks.removeRange(1, 3); // error: removeRange(int,int) has protected access in ArrayList
}
}removeRange(1, 3) removes the items at positions 1 and 2 (61 and 48), so the program prints Marks kept: [56, 73, 80]. The commented line fails because CrossPackageDemo is neither in java.util nor a subclass of ArrayList.
Outside its package, a subclass may use an inherited protected member only through its own type: through this, super, or a variable of the subclass type. Inside MarksList, calling removeRange on another MarksList object is allowed, but calling it on a plain ArrayList variable is not; the compiler again says removeRange(int,int) has protected access in ArrayList. The idea is that a subclass may work on its own kind of object, not on every object of the parent class.
When a subclass overrides a protected method, it may keep it protected or widen it to public, but never narrow it. Overriding protected void show() with a plain void show() (default access) fails with attempting to assign weaker access privileges; was protected.
Use protected for members that subclasses genuinely need, such as a method that each kind of subclass fills in differently, while keeping them away from unrelated classes. Fields are usually still safest as private, with protected or public methods for subclasses to use.