Does 'protected' offer wider access than 'package' level?

tb864615.OCPJAVASE17PT.c03.099

I was surprised to find this compiles.
Since the derived class does not access members in the package outside the base class, I thought that package has wider access than protected.
However since this code compiles, it means 'protected' offers wider access than 'package' level?

abstract class Triangle {    abstract String getDescription(); } abstract class IsoRightTriangle extends RightTriangle { // g1    public String getDescription() { return "irt"; } } public class RightTriangle extends Triangle {    protected String getDescription() { return "rt"; }  // g2    public static void main(String[] edges) {        final var shape = new RightTriangle();        // g3        System.out.print(shape.getDescription());    } }

Your assumption is correct --  the protected access modifier is less restrictive than the package (default) access level

Mikalai Zaikin wrote:Your assumption is correct --  the protected access modifier is less restrictive than the package (default) access level

I don't understand why it compiled.
As I understand, the implementing method should have wider access.
But here, the implementing method is protected (narrower) but the abstract method is package level (wider).

Anil Philip wrote:As I understand, the implementing method should have wider access.

Wider, meaning less restrictive, yes.  Or equally restrictive.

Anil Philip wrote:But here, the implementing method is protected (narrower) but the abstract method is package level (wider).

But protected is less restrictive than package, meaning it is wider, not narrower, than package.

Mike Simmons wrote:
But protected is less restrictive than package, meaning it is wider, not narrower, than package.

I don't understand.
Since the derived class does not access members in the package outside the base class, I thought that package has wider access than protected.

Anil Philip wrote:the derived class does not access members in the package outside the base class

package has wider access than protected

I see absolutely no logical connection between these two statements.

How would the first statement imply the second?

From a derived class, you can access:

Any protected or public member of a super class in another package.
Any public, protected, or package-access members of a class in the same package.
Any members, even private, of the same top-level class.

The second of these conflicts a bit with your statement:

Anil Philip wrote:the derived class does not access members in the package outside the base class

A derived class can access members of the same package as the derived class, outside any base class.  Try it - it works!

Stephan van Hulst wrote:

Anil Philip wrote:the derived class does not access members in the package outside the base class

package has wider access than protected

I see absolutely no logical connection between these two statements.

How would the first statement imply the second?

A garage door has (or allows) wider access than the door to a house.
Since 'protected' does not allow access to the other members of the package of the base class (from the derived class),
protected is more restrictive.
Hence I thought that package is wider than protected.

Anil Philip wrote:'protected' does not allow access to the other members of the package of the base class (from the derived class)

And how did you arrive at this statement?

Stephan van Hulst wrote:

Anil Philip wrote:'protected' does not allow access to the other members of the package of the base class (from the derived class)

And how did you arrive at this statement?

I am trying to write a program to test this. Unsuccessful so far...

Diet is in Package Wolf and is not accessible from the derived class. Trying to code it with something that is protected.

package beyond_classes.wolf; enum Diet {    LOVES("deer"), HATES("chicken");    String food;    Diet(String food) {        this.food = food;    } }

package beyond_classes.wolf; public class GreyWolf {    protected String location = "Wisconsin";    Diet cuisine;    public GreyWolf() { }    protected void run() {} }

package beyond_classes.dog; import beyond_classes.wolf.Diet; import beyond_classes.wolf.GreyWolf; public class GermanShepherd extends GreyWolf {    Diet hates; // DOES NOT COMPILE    public GermanShepherd() {}    protected void run() {        Diet prefers = Diet.LOVES; // DOES NOT COMPILE    }    public static void main(String[] args) {        GermanShepherd gsd = new GermanShepherd();        gsd.run();    } }

I wonder why you assumed the Diet can be accessed outside its package?

Please check JLS 6.6.1: https://docs.oracle.com/javase/specs/jls/se17/html/jls-6.html

If a top level class or interface is declared with package access, then it may be accessed only from within the package in which it is declared.

Mikalai Zaikin wrote:I wonder why you assumed the Diet can be accessed outside its package?

Please check JLS 6.6.1: https://docs.oracle.com/javase/specs/jls/se17/html/jls-6.html

If a top level class or interface is declared with package access, then it may be accessed only from within the package in which it is declared.

I am trying to understand which has wider access; package or protected.
I don't know the answer.
I want to see it in a program like this.

A simple example. Here's a base class in package a:
package com.example.a; public class Service {    protected void protectedMethod() {}    void packagePrivateMethod() {} }
Here's a class that doesn't derive from the base class, but is in the same package a:
package com.example.a; public class SamePackage {  private Service service;  void testCallsFromSamePackage() {    service.protectedMethod();      // No problem. Protected members are accessible in the same package.    service.packagePrivateMethod(); // No problem.  } }
Finally, here is a class in a different package b, that derives from the base class.
package com.example.b; import com.example.a.Service; public class DerivedService extends Service {  void testCallsFromDifferentPackage() {    this.protectedMethod();      // No problem. This class derives from Service, so it can access its protected members.    this.packagePrivateMethod(); // Compilation error. You can't access package private members from a different package.  } }
As you can see, you can access protected members from a class within the same package (even when the class doesn't derive from the base class); but you can't access package private members from a class in a different package that does derive from the base class.

Therefore, protected access is less restrictive than package private access. You could say protected access is 'wider' than package private access, but the preferred phrasing is "protected members have greater visibility than package private members".

Stephan van Hulst wrote: but the preferred phrasing is "protected members have greater visibility than package private members".

So what you are saying is; protected members can be accessed from the same package and also from the derived class. But package-private members can only access each other within the same package.
Thank you. I had been struggling to understand. Your sentence above was key to my getting it finally. "protected members have greater visibility than package private members"

If only it had been stated previously...

Mike Simmons wrote:If only it had been stated previously...

I agree about 'protected' having greater visibility, but I don't see why one can say that 'protected' has wider access.
In the derived class DerivedService, it has lost access to the package members of com.example.a
In Stefan's example, if from the body of com.example.b.Service.protectedMethod(), (just suppose) it could access not only everything in DerivedService and also com.example.b (as expected),
but also everything in the original package com.example.a - then it has not only kept access that base class Service had, but also gained additional access to com.example.b and then one can say that 'protected' has wider access.
Perhaps it is a misnomer?

I agree. We really don't need a long thread on the meaning of the word "wider". It's really more useful to learn how the modifiers work in practice.

Paul Clapham wrote:I agree. We really don't need a long thread on the meaning of the word "wider". It's really more useful to learn how the modifiers work in practice.

Some of the questions on the practice tests ask you which modifier provides 'wider' (or sometimes the word 'more') access.

Well, now you know. By wider, they mean higher visibility, and protected members are more visible than package private members.

Anil Philip wrote:I agree about 'protected' having greater visibility, but I don't see why one can say that 'protected' has wider access.
In the derived class DerivedService, it has lost access to the package members of com.example.a

I don't think it ever had access, so I wouldn't say it lost anything.

Anil Philip wrote:In Stefan's example, if from the body of com.example.b.Service.protectedMethod(), (just suppose) it could access not only everything in DerivedService and also com.example.b (as expected),
but also everything in the original package com.example.a - then it has not only kept access that base class Service had, but also gained additional access to com.example.b and then one can say that 'protected' has wider access.
Perhaps it is a misnomer?

So, there is no com.example.b.Service.protectedMethod().  I guess you mean, if we put one there, and if we were calling other stuff from that method.  But that's beside the point.  It sounds like you're thinking that if a method is protected, it might confer more power to access stuff outside that method.  That's backward.  A modifier like "protected" on a method does not affect what that method can see or access.  Rather, it affect whether outside code can see or access that method.  That's why Stefan's code is testing what can be seen or accessed from other locations, namely com.example.a.SamePackage and com.example.b.DerivedService, which are testing their ability to access com.example.a.Service.protectedMethod() and access com.example.a.Service.packagePrivateMethod().

Thanks - I understood now.