Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Ambiguous statement on page 237? (Java OCA 8 Programmer I Study Guide)

 
Raghavendra Desoju
Ranch Hand
Posts: 95
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

On page 237, I see following in third paragraph:

"The public access modifier applied to a class indicates that it can be referenced and used in any class. The default package private modifier, which is the lack of any access modifier, indicates the class can be accessed only by a subclass or class within the same package."

Below is my understanding of accessibility:-

public -> accessible by entire world.
protected -> classes in same package and sub classes.
default --> classes in same package.
private --> within the class.

Please clarify.

Thanks,
Raghu

 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raghavendra Desoju wrote:The default package private modifier, which is the lack of any access modifier, indicates the class can be accessed only by a subclass or class within the same package.

The statement doesn't mention the subclass can be in another package as well, it states "subclass or class within the same package". So for me that's a correct statement.

Raghavendra Desoju wrote:Below is my understanding of accessibility:-

Your understanding is spot-on! And your overview could be a summary of this slightly changed/extended version (changes are underlined):
  • public -> accessible by entire world
  • protected -> classes and subclasses in same package and subclasses in other packages
  • default --> classes and subclasses in same package
  • private --> within the class


  • Hope it helps!
    Kind regards,
    Roel
     
    Paweł Baczyński
    Bartender
    Posts: 1877
    35
    Firefox Browser IntelliJ IDE Java Linux Spring
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Roel De Nijs wrote:The statement doesn't mention the subclass can be in another package as well, it states "subclass or class within the same package". So for me that's a correct statement.


    It is correct but it is also ambiguous (at least for me and OP).

    You can understand a subclass or class within the same package two ways

    1. (a subclass) OR (a class within the same package)
    2. (a class or subclass) [WHERE?] within the same package

    My first impression was option 1.

    A subclass is also a class so second option sounds like a rectangle or a square so my instinct suggested option 1 as it would make more sense.
     
    Roel De Nijs
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Paweł Baczyński wrote:
    Roel De Nijs wrote:The statement doesn't mention the subclass can be in another package as well, it states "subclass or class within the same package". So for me that's a correct statement.


    It is correct but it is also ambiguous (at least for me and OP).

    I just have read the sections about "default (package private) access" and "protected access" in the study guide on pages 175 and 176.

    And I agree with the statement on page 237 being ambiguous: the "default (package private) access" section states clearly "only classes in the same package can access it", so no "subclass" is mentioned. So for consistency and to avoid ambiguity, the statement on page 237 should be changed to "The default package private modifier, which is the lack of any access modifier, indicates the class can be accessed only by classes within the same package."

    And in the "protected access" section I read this statement:
    The protected access modifier adds the ability to access members of a parent class
    That statement is incomplete (wrong)! It should be "The protected access modifier adds the ability to access members of a parent class in a different package". Because with default (package private) access (when you don't use an access modifier) you already can access members of the parent class, if subclass and parent class are defined in the same package.

    Hope it helps!
    Kind regards,
    Roel
     
    Jeanne Boyarsky
    author & internet detective
    Marshal
    Posts: 35279
    384
    Eclipse IDE Java VI Editor
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Roel De Nijs wrote:And in the "protected access" section I read this statement:
    The protected access modifier adds the ability to access members of a parent class
    That statement is incomplete (wrong)! It should be "The protected access modifier adds the ability to access members of a parent class in a different package". Because with default (package private) access (when you don't use an access modifier) you already can access members of the parent class, if subclass and parent class are defined in the same package.

    I don't think this is wrong. (I wonder if this is another English thing.) I agree it isn't extremely precise, but I don't think it is wrong.

    Here's why:


    This code first adds "a" to the set. It then adds "a" and "b". It so happens that "a" was already in there so adding it has no effect. But it is still in there.

    I've added this thread to my private list of things that could be clearer if we write a Java 9 version of this book. I'm not sold on it being an errata yet. Keep in mind that you want to a study guide to be readable and assist in remembering. If you want dry and exacting, read the spec. If a reader remembers that "protected adds subclasses", he/she will get the question right.
     
    Guillermo Ishi
    Ranch Hand
    Posts: 789
    C++ Linux Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Raghavendra Desoju wrote:Hi,
    public -> accessible by entire world.

    Remember that for all 4 levels you still have to import the package. And that if the public was in an unnamed packed it would only be package access because there's no way to import an unnamed package.
     
    Roel De Nijs
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Guillermo Ishi wrote:
    Raghavendra Desoju wrote:Hi,
    public -> accessible by entire world.

    Remember that for all 4 levels you still have to import the package.

    That's not a requirement if you use the fully qualified class name
     
    Guillermo Ishi
    Ranch Hand
    Posts: 789
    C++ Linux Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Roel De Nijs wrote:
    Guillermo Ishi wrote:
    Raghavendra Desoju wrote:Hi,
    public -> accessible by entire world.

    Remember that for all 4 levels you still have to import the package.

    That's not a requirement if you use the fully qualified class name

    This stuff is really so complicated that it's hard to make a statement that's fully accurate... K&B is guilty too. You were guilty when you didn't include any of this in your first response.
     
    Roel De Nijs
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Guillermo Ishi wrote:You were guilty when you didn't include any of this in your first response.

    No, I wasn't! I didn't mention anything about the import statement, because that simply doesn't matter regarding the ambuguous statement we are discussing here...
     
    Jeanne Boyarsky
    author & internet detective
    Marshal
    Posts: 35279
    384
    Eclipse IDE Java VI Editor
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Moderator hat:
    Calm down. Let's avoid words like "guilty".

    Author hat:
    As fascinating as these English discussions are, what is the goal supposed to be? I've already said that I've noted it if we do an OCA 9 book and that it's not an errata because I don't believe it is wrong. Are you trying to convince me I'm wrong? Or is it just an interesting discussion on English? Because if the latter, maybe the thing to do is start a new thread in MD to discuss the finer points of the English language.
     
    Roel De Nijs
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Jeanne Boyarsky wrote:
    Roel De Nijs wrote:And in the "protected access" section I read this statement:
    The protected access modifier adds the ability to access members of a parent class
    That statement is incomplete (wrong)! It should be "The protected access modifier adds the ability to access members of a parent class in a different package". Because with default (package private) access (when you don't use an access modifier) you already can access members of the parent class, if subclass and parent class are defined in the same package.

    I don't think this is wrong. (I wonder if this is another English thing.) I agree it isn't extremely precise, but I don't think it is wrong.

    It's indeed not wrong, but it could be misleading. And I don't think it's an English thing but it's related with the (incremental) build up of the "Applying Access Modifiers" section:
  • first the book starts with "private access", only code in the same class can access private members
  • then it's about "default (package private) access", only classes in the same package can access the package-private members of another class
  • next in the row is "protected access", the same as "default access" + subclasses in another package can access members of a parent class as well (if the parent class is accessible as well of course)
  • and finally it's about "public access", any class can access public members (if the class is accessible as well of course)


  • So it's from this build up that I made my comment about the statement being incomplete.

    Jeanne Boyarsky wrote:If a reader remembers that "protected adds subclasses", he/she will get the question right.

    True! But the reader could also think that in the same package a member has to be protected to be able to be accessed by a subclass in the same package (because that's what he remembered "protected adds subclasses").

    Just my 2 cents.
     
    Guillermo Ishi
    Ranch Hand
    Posts: 789
    C++ Linux Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    When a beginner (such as I) sees "public -> accessible by entire world" without any requirements or caveats he naturally assumes that's all there is to it. They would not be asking the question if they knew enough already to know the caveats. The whole truth needs to be reinforced all the time, every time. K & B usually does that, somewhere later in the paragraph -- so be careful to read the whole paragraph
     
    Paweł Baczyński
    Bartender
    Posts: 1877
    35
    Firefox Browser IntelliJ IDE Java Linux Spring
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Guillermo Ishi wrote:The whole truth needs to be reinforced all the time, every time.

    On the other hand, at some point an author must assume a reader already knows that using a class from a different package requires importing it first (or using its fully qualified name).
    It would be horribly difficult to write anything if you had to repeat everything all the time... (I guess, I never wrote any book )
     
    Roel De Nijs
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Paweł Baczyński wrote:It would be horribly difficult to write anything if you had to repeat everything all the time... (I guess, I never wrote any book )

    And not only that, but you'll probably end up with a book of 2000 pages instead of 900
     
    Guillermo Ishi
    Ranch Hand
    Posts: 789
    C++ Linux Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Paweł Baczyński wrote:
    Guillermo Ishi wrote:The whole truth needs to be reinforced all the time, every time.

    On the other hand, at some point an author must assume a reader already knows that using a class from a different package requires importing it first (or using its fully qualified name).
    It would be horribly difficult to write anything if you had to repeat everything all the time... (I guess, I never wrote any book )


    Horribly difficult or not... In a book at least, if you've already said something, you just need to be careful elsewhere. One thing you could do would be to reiterate when something otherwise might read like a contradiction.

    Here's the example I'm talking about, from K&B, that I used in this thread.
    "In other words, all classes in the Java Universe (JU) have access to a public class. Don't forget, though, that if a public class you're trying to use is in a different package from the class you're writing, you'll still need to import the public class." I agree with Roel they ought to tack "or fully qualified name" onto it too. That would do two things -- it would make it more accurate, and also it could well be the first place they ever hear the term fully qualified name.

    Incidentally something K&B does that could be fixed is in their books they say "Think of an interface as a 100-percent abstract class." That implies abstract classes and interfaces have more in common than they do.
     
    Roel De Nijs
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Guillermo Ishi wrote:That would do two things -- it would make it more accurate, and also it could well be the first place they ever hear the term fully qualified name.

    The fully qualified name is mentioned at the bottom of page 13 in the "Import Statements and the Java API" section. And that section explains in great detail what's the purpose of an import statement and its sole benefit (less typing). So at the point the reader reaches the statement you mentioned (bottom of page 19), the reader should already know what the purpose of an import statement is (and thus if you don't use it, you should use the fully qualified name of the class). But maybe for the sake of repetition, it might be a good idea to add "(or use the fully qualified name)" to that statement.

    Guillermo Ishi wrote:That implies abstract classes and interfaces have more in common than they do.

    Both can be considered to be equivalent, certainly if you don't store state and define behavior in your abstract class. (And with Java 8 and default methods, the difference between interfaces and abstract classes fades even more)
     
    Liutauras Vilda
    Bartender
    Pie
    Posts: 2788
    112
    BSD VI Editor
    • Likes 2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Guillermo Ishi wrote:Horribly difficult or not... In a book at least, if you've already said something, you just need to be careful elsewhere. One thing you could do would be to reiterate when something otherwise might read like a contradiction.

    Authors definitely double checking what they write, but it is nearly impossible to avoid slight inaccuracy in using words (words are not numbers), nevertheless, you should always triple check using practical approach.

    And this is what authors encourage you - do a lot exercises. You might think it is not that important, but these tips, given by authors, suppose to be taken seriously for the next it seems simple advantages:
  • It would help you to understand the topic from the practical perspective
  • Researching specific concept usually puts you on a right track to discover corner cases
  • After you discover them in practice - it remains longer in your head

  • There are more advantages, but these should be enough to convince yourself why you should follow authors suggestions.
    And probably such a situations wouldn't trick you anymore
     
    Guillermo Ishi
    Ranch Hand
    Posts: 789
    C++ Linux Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Roel De Nijs wrote:
    Guillermo Ishi wrote:That implies abstract classes and interfaces have more in common than they do.

    Both can be considered to be equivalent, ...


    All they have in common is they can have methods without bodies. Very misleading for the purposes of testing. Speaking of 7, not concerned with 8.
     
    Roel De Nijs
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Guillermo Ishi wrote:All they have in common is they can have methods without bodies.

    Not true! They are both abstract, they can both define constants and they can both be used to refer to a (concrete) implementation. And additionally an abstract class can have state and behavior defined (which an interface - in Java 7 - can't).

    Let's have a look at this abstract classThe only thing I have to do now, is simply change class to interface and I'm doneSo I would say that's pretty similar/equivalent.

    Guillermo Ishi wrote:Incidentally something K&B does that could be fixed is in their books they say "Think of an interface as a 100-percent abstract class." That implies abstract classes and interfaces have more in common than they do.

    I have another interpretation of that quote. You have an abstract class which can have abstract and concrete methods. An interface is a 100-percent abstract class, so you can't have concrete methods only abstract ones. (So that's probably a statement which will not be in the Java 8 edition anymore)

    Hope it helps!
    Kind regards,
    Roel
     
    Guillermo Ishi
    Ranch Hand
    Posts: 789
    C++ Linux Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    LOL! If you set it up right, you can change one word and have an abstract class become a concrete class. That does not mean the two are "pretty similar/equivalent"

    For testing, the difference between abstract class and interface is huge. One big thing is implied types of fields and the consequences of that in tricky questions. Also must use "abstract" keyword with methods in abstract classes. But you know all this, obviously. There are more differences than there are similarities.

    Yes, if you take it to only mean that an interface can have only methods without bodies, it is 100% abstract, then you could say it makes sense. But -- there is more to both than that, and the statement does imply they are more alike than they are.
     
    Roel De Nijs
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Guillermo Ishi wrote:LOL! If you set it up right, you can change one word and have an abstract class become a concrete class.

    Really curious how a one word change will turn this abstract Calculator class into a concrete class...

    Guillermo Ishi wrote:One big thing is implied types of fields and the consequences of that in tricky questions.

    And what do you mean with "implied types of fields"?

    Guillermo Ishi wrote:But -- there is more to both than that, and the statement does imply they are more alike than they are.

    It's probably a difference in interpretation. I have been on this forum for a while and as far as I can remember you are the first one mentioning it should be fixed.

    Me personally, I have read that statement a few times and I didn't have any issues with it, because it's nicely explained in that same paragraph:
    K&B7, Declaring an Interface, p24 wrote:Like an abstract class, an
    interface defines abstract methods that take the following form:

    But while an abstract class can define both abstract and non-abstract methods, an interface can have only abstract methods. Another way interfaces differ from abstract classes is that interfaces have very little flexibility in how the methods and variables defined in the interface are declared. These rules are strict:
    And then all strict rules (9 in total) are listed.
     
    Paul Anilprem
    Enthuware Software Support
    Ranch Hand
    Posts: 3817
    10
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Wait a minute. What are we discussing about???

    Individual sentences of explanations can never be 100% accurate. A definition is supposed to be 100% accurate. An explanation decompresses a definition into a thousand words so that it can be understood a bit more easily. You are "breaking it down" when you try to explain something, so how can you pick pieces of that and expect them to be precise and unambiguous? You can't understand JLS, that is why you need a book to "break it down" for you! Is it not?

    But yes, when you read the whole explanation,a complete paragraph, or a complete section of an explanatory text, it should tell you the complete story.
     
    Guillermo Ishi
    Ranch Hand
    Posts: 789
    C++ Linux Python
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    By "implied types of fields" in interfaces, I meant modifiers that are in effect for variables in interfaces, even if they're not explicitly in the code. I wouldn't single out "Think of an interface as a 100-percent abstract class" and say it should be fixed, but it could be fixed. I do remember it at some point making me think the two were more alike than they are. In short, "Think of an interface as a 100-percent abstract class" might not be the best way to think of an interface
     
    Roel De Nijs
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Guillermo Ishi wrote:By "implied types of fields" in interfaces, I meant modifiers that are in effect for variables in interfaces, even if they're not explicitly in the code.

    Aaah! If you would have said "implied modifiers of fields", I would have understood from the first time
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic