File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes private and protected class - why not? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "private and protected class - why not?" Watch "private and protected class - why not?" New topic
Author

private and protected class - why not?

ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Why protected class is not allowed in Java (and default (no access modifier) is allowed)?

Why private class is not allowed in Java (final keyword is allowed, private constructor is allowed - these two make a class not useful for other classes)?

Thanks.

PS: Not talking about inner classes.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36599
    
  16
Both are permitted, but only as inner or nested classes.

If you have a private inner or nested class, then access is restricted to the scope of that outer class. If you have a private class on its own as a top-level class, then you can't get access to it from anywhere.

If you have a protected inner or nested class, then access is permitted from inside the same package or subclasses of the outer class or something similar. If you have a protected top-level class there isn't an outer class to have subclasses to gain access from, so protected is meaningless.

Making a class final and giving it a private constructor mean that you have to work out some other way of giving access, maybe via public static methods, or a public static getInstance() method.
The final bit really means you are not allowed to extend the class. It is not usually possible to extend a top-level class with only private constructors.
Leon Omk
Ranch Hand

Joined: Aug 17, 2010
Posts: 75

PS: Not talking about inner classes.


Why protected non-inner-class is not allowed in Java? Help!


OK, so that other guy knows Java better than I do, but I bet he can't speak Wuhanese(a Chinese Dialect) like me.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36599
    
  16
Tell us which class it is "protected" to.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4246
    
    7

And what would be the point of a private class? A class that no other class can see, and therefore can't be used for anything?
Alex Hurtt
Ranch Hand

Joined: Oct 26, 2010
Posts: 98
Leon Omk wrote:
PS: Not talking about inner classes.


Why protected non-inner-class is not allowed in Java? Help!


Maybe if you can explain to us what you are trying to do and why you perceive the absence of protected non-inner classes in java to be a problem for you we can help you clear up your misconceptions. The fact that you think there need to be such classes probably is indicative of some fundamental misunderstanding which needs to be put right. You likely have some desired outcome in mind that you are trying to accomplish but are thinking about the problem in the wrong terms or something. But we can't know how to help unless you explain to us what you are trying to do.
J. Insi
Ranch Hand

Joined: Aug 11, 2010
Posts: 84
he3.
wish this source is easy to understand for you
Here Here Take a Read
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18165
    
    8

J. Insi wrote:Here Here Take a Read


Actually... don't bother with that link. Two reasons:

  • It doesn't address the original question at all
  • Worse than that, it doesn't even give the correct definition for "protected"


  • So no, don't bother.
    Leon Omk
    Ranch Hand

    Joined: Aug 17, 2010
    Posts: 75

    Thanks Alex.

    In my imagination, a "protected" class should be:
    1. only visible to Class which extends it
    2. instantiation is allowed, but only within the Class which extends it





    When I invoke: new CurrentLife().whoWasI(), I expect "A happy man! A crazy man!". So that's the "protected class" in my dream.
    Stephan van Hulst
    Bartender

    Joined: Sep 20, 2010
    Posts: 3401
        
        9
    But that's not what protected means, is it? Something that is protected is something that's only visible to classes that extend the enclosing class of the protected member.

    So how can a top level class be protected? It doesn't have an enclosing class, does it?

    Private top level classes aren't allowed because they are useless. Protected top level classes aren't allowed because protected simply can't be applied to them by the definition of protected.
    Paul Clapham
    Bartender

    Joined: Oct 14, 2005
    Posts: 18165
        
        8

    Stephan van Hulst wrote:But that's not what protected means, is it? Something that is protected is something that's only visible to classes that extend the enclosing class of the protected member.


    I don't think that's quite correct. Quoting from Oracle's tutorial Controlling Access to Members of a Class:

    Oracle wrote:The protected modifier specifies that the member can only be accessed within its own package (as with package-private) and, in addition, by a subclass of its class in another package.


    People tend to forget the first part of that specification, and that's what makes this question not totally trivial.
    Alex Hurtt
    Ranch Hand

    Joined: Oct 26, 2010
    Posts: 98
    Leon Omk wrote:Thanks Alex.

    In my imagination, a "protected" class should be:
    1. only visible to Class which extends it
    2. instantiation is allowed, but only within the Class which extends it





    When I invoke: new CurrentLife().whoWasI(), I expect "A happy man! A crazy man!". So that's the "protected class" in my dream.


    So do you imagine that by protecting the whole class it would automatically apply the protected access modifier to all methods/members in the class? But what then would happen if there was a specific method or member in the class that you wanted to have only default (package-friendly) access level? What modifier would you use on this member or method to signify that? Sure you could add private methods since there's a specific access modifier keyword for that. You couldn't really add public methods or members because doing so would be sort of along the lines of adding a public method to a default access level class...the class access level would override the public modifier on any public methods you declared making them effectively package friendly also (it doesn't matter if you have public methods, you can't see or invoke them if you can't see or instantiate the class that owns them). If you protect the whole class then everything is going to be inheritable by other subclasses even in other packages. You might not really want this but you'd have no way of preventing it because there is no explicit 'default (package-friendly)' access modifier keyword.

    There is a new feature in Java 7 which may help achieve an effect something like what you are thinking of called super packages.
    Steve Luke
    Bartender

    Joined: Jan 28, 2003
    Posts: 3971
        
      17

    Alex Hurtt wrote:
    So do you imagine that by protecting the whole class it would automatically apply the protected access modifier to all methods/members in the class?


    I don't think you need to make that assumption at all. Default Accessible Classes don't make that assumption. A default accessible class with a public method and a public subclass has its public method inherited by the subclass, and thus made visible to all other classes:


    I don't see why Protected classes couldn't do the same thing (conceptually).

    But what then would happen if there was a specific method or member in the class that you wanted to have only default (package-friendly) access level? What modifier would you use on this member or method to signify that?


    The access level for the class does not affect the access level of any of its members, as seen above. The members are normally accessible according to the rules of their own access level.

    Sure you could add private methods since there's a specific access modifier keyword for that. You couldn't really add public methods or members because doing so would be sort of along the lines of adding a public method to a default access level class...the class access level would override the public modifier on any public methods you declared making them effectively package friendly also (it doesn't matter if you have public methods, you can't see or invoke them if you can't see or instantiate the class that owns them).


    But as the above example shows - first you can have methods with a higher visibility than their containing class - second you can have a subclass with more visibility than its parent - and finally when you have the two, then the method in the parent class has visibility as defined by its access level - not its containing class. So the access modifier of the class does not override the access modifier of the member.

    If you protect the whole class then everything is going to be inheritable by other subclasses even in other packages. You might not really want this but you'd have no way of preventing

    But this problem is the same with the default access level classes. They can be subclasses by public classes in the same package - which then makes them accessible from other packages.

    it because there is no explicit 'default (package-friendly)' access modifier keyword.

    But you don't need one. If you want it 'package private' you don't add any other modifier. Why would this change?

    Steve
    Alex Hurtt
    Ranch Hand

    Joined: Oct 26, 2010
    Posts: 98
    Steve Luke wrote:
    Alex Hurtt wrote:
    So do you imagine that by protecting the whole class it would automatically apply the protected access modifier to all methods/members in the class?


    I don't think you need to make that assumption at all. Default Accessible Classes don't make that assumption. A default accessible class with a public method and a public subclass has its public method inherited by the subclass, and thus made visible to all other classes:


    I'm not making that assumption, I'm asking a question to try and understand how Leon imagines that the notion of a 'protected class' would work. But anyway, a default accessible class with a public method is only sub-classable in the same package is the problem. If you want to subclass the class in any other package it has to be a public class, no?

    Steve Luke wrote:


    I don't see why Protected classes couldn't do the same thing (conceptually).

    But what then would happen if there was a specific method or member in the class that you wanted to have only default (package-friendly) access level? What modifier would you use on this member or method to signify that?


    The access level for the class does not affect the access level of any of its members, as seen above. The members are normally accessible according to the rules of their own access level.

    Sure you could add private methods since there's a specific access modifier keyword for that. You couldn't really add public methods or members because doing so would be sort of along the lines of adding a public method to a default access level class...the class access level would override the public modifier on any public methods you declared making them effectively package friendly also (it doesn't matter if you have public methods, you can't see or invoke them if you can't see or instantiate the class that owns them).


    But as the above example shows - first you can have methods with a higher visibility than their containing class - second you can have a subclass with more visibility than its parent - and finally when you have the two, then the method in the parent class has visibility as defined by its access level - not its containing class. So the access modifier of the class does not override the access modifier of the member.

    If you protect the whole class then everything is going to be inheritable by other subclasses even in other packages. You might not really want this but you'd have no way of preventing

    But this problem is the same with the default access level classes. They can be subclasses by public classes in the same package - which then makes them accessible from other packages.

    it because there is no explicit 'default (package-friendly)' access modifier keyword.

    But you don't need one. If you want it 'package private' you don't add any other modifier. Why would this change?




    Now if you want to say that a 'protected' class would behave like an interface where all the declared methods were always public and you can't have any other kind then ok (except in the case of the protected class the default level would be protected)...but I'm assuming (and remember this is all hypothetical since there is currently no such thing as a 'protected' top level class) you might still want to have some private, some default, and some public methods thrown in there. Or maybe the original intent the author of the post had in mind was to redefine the actual meaning of 'protected.' Idunno.
    Steve Luke
    Bartender

    Joined: Jan 28, 2003
    Posts: 3971
        
      17

    The original question is: Why can a class be either publicly accessible or package private? Why can't it be, for example, protected? When the question is asked, it is about the access to the class, and I don't think there is any reason that question has to be associated with re-defining what member accessibility means (after all you don't need to re-define member accessibility between public classes and dafault accessible classes). So I guess when you ask this:
    So do you imagine that by protecting the whole class it would automatically apply the protected access modifier to all methods/members in the class?

    The answer for me would be: No, I don't imagine that at all.

    Now if you want to say that a 'protected' class would behave like an interface where all the declared methods were always public and you can't have any other kind then ok (except in the case of the protected class the default level would be protected)...

    I don't want to say that.

    If you are wondering what I would mean by a protected class it would be one that is accessible to other classes in the same package and any class which sub-classes it.
    I don't think I see a reason to have protected classes - but I also don't see why not (other than by definition). My one concern would be: Any class which sub-classes a protected class would mean classes in a different package would need access for purposes of sub-classing it, so there could be a 'chicken-or-the-egg' happening here - you can only sub-class classes you have access to, and you would only have access to the protected class if you sub-classed it. Is this sort of circular dependency solvable? Maybe that is why there are no protected classes... dunno.
    Greg Charles
    Sheriff

    Joined: Oct 01, 2001
    Posts: 2771
        
      10

    Leon, what you're trying to do is possible with a public base class with protected constructors. You could even declare the base class abstract as a way of showing it can't be instantiated directly, but that's not technically necessary. Other classes could see the base class, but they couldn't actually do anything with it except through one of the subclasses. Only classes that extended the base class could actually cause it to be instantiated.

    Also, declaring a class protected so that nothing could see it except a class that was extending it sounds like a chicken-and-egg problem to me. If you can't see it, how can you extend it?
    Paul Clapham
    Bartender

    Joined: Oct 14, 2005
    Posts: 18165
        
        8

    Greg Charles wrote:Also, declaring a class protected so that nothing could see it except a class that was extending it sounds like a chicken-and-egg problem to me. If you can't see it, how can you extend it?


    Actually it would be "nothing could see it except a class that was extending it or a class in the same package". If we write off the first part as meaningless, what is left is a package-private class. Which is a permitted modifier.

    But if we attempt to assign a meaning to the first part, then there are two possibilities:

    (1) Nothing outside the protected class's package can extend it -- this is equivalent to making it package-private.
    (2) Anything can extend it -- this is equivalent to making it public.

    So that's pretty useless. But then there's the question of what classes can refer to the type:

    At this point I suspect the Java designers just said "$%^^# that, we just won't allow it!"
    Alex Hurtt
    Ranch Hand

    Joined: Oct 26, 2010
    Posts: 98
    Paul Clapham wrote:
    Greg Charles wrote:Also, declaring a class protected so that nothing could see it except a class that was extending it sounds like a chicken-and-egg problem to me. If you can't see it, how can you extend it?


    Actually it would be "nothing could see it except a class that was extending it or a class in the same package". If we write off the first part as meaningless, what is left is a package-private class. Which is a permitted modifier.

    But if we attempt to assign a meaning to the first part, then there are two possibilities:

    (1) Nothing outside the protected class's package can extend it -- this is equivalent to making it package-private.
    (2) Anything can extend it -- this is equivalent to making it public.

    So that's pretty useless. But then there's the question of what classes can refer to the type:

    At this point I suspect the Java designers just said "$%^^# that, we just won't allow it!"


    I think this sums it up. I think the problem is that the question "why no protected classes?" was posed but a protected class in Java is an undefined thing...it doesn't exist and the person posing the question did not define it in terms of "why can't there be a protected class and it would work exactly like this...." So we are left to guess and hypothesize as to what exactly a 'protected class' could be. Clearly, for reasons outlined in this thread, the definition of protected as it exists today doesn't really make sense when you apply it at the class level so we are left to wonder if having a protected class would mean having to redefine the role of the protected modifier in Java? You might just as well have posed the question "Why doesn't java have Norfle-dibbits?" Well tell me exactly what a norfle-dibbit is and maybe I can tell you why they aren't in Java...
    Steve Luke
    Bartender

    Joined: Jan 28, 2003
    Posts: 3971
        
      17

    Alex Hurtt wrote:...I think the problem is that the question "why no protected classes?" was posed but a protected class in Java is an undefined thing...it doesn't exist and the person posing the question did not define it in terms of "why can't there be a protected class and it would work exactly like this...." So we are left to guess and hypothesize as to what exactly a 'protected class' could be. Clearly, for reasons outlined in this thread, the definition of protected as it exists today doesn't really make sense when you apply it at the class level so we are left to wonder if having a protected class would mean having to redefine the role of the protected modifier in Java? You might just as well have posed the question "Why doesn't java have Norfle-dibbits?" Well tell me exactly what a norfle-dibbit is and maybe I can tell you why they aren't in Java...


    I disagree with the fact that 'protected class' is the same as 'norfle-dibbits'. The access modifier 'protected' is well defined in the java language specifications. I think Paul's post clears up just why the concept is not useful - to effectively apply the term to a top level class you have to define how extending a protected class works - and any such clarification just makes it the same as either the 'package-private' or public classes.

    My only counter point would be such an edge case it probably isn't worth mentioning:
    The only theoretical case I can come up with where a substitute of public or default access (with proper member access control) wouldn't suffice would be where you wanted to explicitly prevent referring to an Object by the protected classes type. For example you want to make this illegal:

    But you still want to be able to have any class extend it. Again, not sure why you would want this... just saying...
    Alex Hurtt
    Ranch Hand

    Joined: Oct 26, 2010
    Posts: 98
    Steve Luke wrote:
    Alex Hurtt wrote:...I think the problem is that the question "why no protected classes?" was posed but a protected class in Java is an undefined thing...it doesn't exist and the person posing the question did not define it in terms of "why can't there be a protected class and it would work exactly like this...." So we are left to guess and hypothesize as to what exactly a 'protected class' could be. Clearly, for reasons outlined in this thread, the definition of protected as it exists today doesn't really make sense when you apply it at the class level so we are left to wonder if having a protected class would mean having to redefine the role of the protected modifier in Java? You might just as well have posed the question "Why doesn't java have Norfle-dibbits?" Well tell me exactly what a norfle-dibbit is and maybe I can tell you why they aren't in Java...


    I disagree with the fact that 'protected class' is the same as 'norfle-dibbits'. The access modifier 'protected' is well defined in the java language specifications.


    Only as it applies to inner classes and member variables/methods. It is undefined as to how it would apply to top level classes and the person posing the question didn't really clarify how he imagined it would work...So in that respect, the notion of a protected top level class in Java is like a norfle-dibbit in that I don't know why it isn't there because I don't know what it is and there is nothing currently in existence I know of anywhere called a 'norfle-dibbit'. That is why I supposed that for protected to be applied to a top level class would require a redefinition of what 'protected' means in Java because it doesn't make much sense to have a protected top level class in Java with protected having its current definition and applicability. So a protected top level class is the same as a norfle-dibbit to me...undefined.
    Steve Luke
    Bartender

    Joined: Jan 28, 2003
    Posts: 3971
        
      17

    I guess we are getting into semantics here. The access modifier 'protected' is defined, and is stated as not applicable to a top level class. And the question is 'why is it not applicable?' I think this is very different than asking about a nonsensical jumble of letters. Perhaps you feel differently.
    Eduard del Corral
    Greenhorn

    Joined: Nov 01, 2012
    Posts: 2
    First off, hello everyone. I'm a newcomer and stumbled upon this thread in an attempt at grasping the core concepts of the Java language.

    Second I'm aware this discussion was abandoned but I found it a very interesting topic.

    Finally I know were talking about Santa's sled speed limit since protected outer classes don't exist; that said, I have a theory of what a protected outer class functionality might be like, and how it's currently attained:


    You first declare a public abstract class which can be extended anywhere but never instantiated.

    From within the package you extend this abstract class with a default class. Now we can instantiate inside the package.*.


    And with this class duo, you get to both instantiate and inherit inside the package. Outside the package we can still inherit this class, but not instantiate. **



    Which is what you'd get with a protected class (if it existed) as far as I understand it.




    * Yes you can inherit your default class within the package, but that's besides the point, we're considering the abstract and default class duo to work as one protected class.

    ** One may represent hiden class elements by simply implementing them in the default extending class.
    Campbell Ritchie
    Sheriff

    Joined: Oct 13, 2005
    Posts: 36599
        
      16
    Welcome to the Ranch
    Agree that scenario would work. It is different from protected access, however; you cannot extend the package‑private (=default access) class outside its package.
    Winston Gutkowski
    Bartender

    Joined: Mar 17, 2011
    Posts: 7081
        
      16

    Eduard del Corral wrote:You first declare a public abstract class which can be extended anywhere but never instantiated.
    From within the package you extend this abstract class with a default class. Now we can instantiate inside the package.*.

    And with this class duo, you get to both instantiate and inherit inside the package. Outside the package we can still inherit this class, but not instantiate. **
    Which is what you'd get with a protected class (if it existed) as far as I understand it.

    I'm afraid I don't quite follow your logic (but maybe it's just me being thick). Assuming we're talking about a client outside the package, in order to "see" something that's protected, you must extend its container. In the case of a protected class, there is no such container unless it's nested (or inner).

    ** One may represent hiden class elements by simply implementing them in the default extending class.

    One may also represent "hidden" class elements by making them private and providing protected methods to access them (or indeed, making them protected; but I wouldn't recommend it).

    As for your "default" class scenario, It sounds to me very much like a "skeleton" implementation, which seems to me to be reasonably handled by the "public interface/public abstract skeleton class" pattern (viz: List/AbstractList).

    But like I say, maybe it's just me being thick. Can you explain exactly where you think your scenario above might be useful?

    Winston


    Isn't it funny how there's always time and money enough to do it WRONG?
    Artlicles by Winston can be found here
    Tushar Bhaware
    Ranch Hand

    Joined: Aug 13, 2012
    Posts: 62

    Matthew Brown wrote:And what would be the point of a private class? A class that no other class can see, and therefore can't be used for anything?

    This clearly explains why there is no private class. Thanks


    Remember you have not inherited earth from your ancestor,you only borrowed it from your descendants.
    Eduard del Corral
    Greenhorn

    Joined: Nov 01, 2012
    Posts: 2
    Winston Gutkowski wrote:
    As for your "default" class scenario, It sounds to me very much like a "skeleton" implementation, which seems to me to be reasonably handled by the "public interface/public abstract skeleton class" pattern (viz: List/AbstractList).

    But like I say, maybe it's just me being thick. Can you explain exactly where you think your scenario above might be useful?

    Winston



    Yes, I imagine them working as skeletons outside the package and standard default classes inside.

    The one reason I can see for them is building a suite of functions, say an image processing package, and hiding some of the package specific elements (mostly any interplay with the package API). So that these functions work well as a package but also offer the alternative of inheriting say a really complex algorithm for which ever purposes the programmer may have in mind. This would probably make more sense if the package was somehow precompiled yet still extendable (which doesn't really apply to Java).

    To be honest since this can already be achieved it's kind of like while and for loops, in that whiles can do anything a for can. However, I wouldn't know if this type of class would make this clearer or actually introduce ambiguity. Which is why I suppose it doesn't exist (redundant, could lead to bad programming habits).


    Anyway, thanks for your reply!

    PS Was actually learning this topic and after a few days of thinking about it came up with said answer. My instructor also considers it irrelevant, but in any case its a fun mental exercise and sometimes you do stumble into interesting things this way.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: private and protected class - why not?
     
    Similar Threads
    enum cannot be private or protected
    Top level class Vs inner classes access specifiers
    asking about public private n protected
    Protected Access Specifier
    enums and protected modifier