[HD Pg 263, Sec. 8.4.3 - understanding-protected-access]

[Username987654]

As a person that has read many certification books over the years (and has forgotten a lot [of the old stuff] since I've always had to juggle many languages concurrently), I just wanted to formally express my appreciation for the following explanation:

It sounds confusing and it is indeed confusing. But if you think about it, it does make
sense. Imagine you develop a class. This class provides some functionality in a way you
deem appropriate. But now you want other people to use your class and also let them
implement, enhance, or tweak that functionality in their own way. You don’t want
them to change the way your class works, you just want to them to be able to reuse
your class and implement that functionality the way they deem fit in their own class.

[admin]

Thank you

[OCAJO1]

When I setup the second set of examples,

Code: Select all

//In file NewHRAccount.java
package com.mybank.newhr;
import com.mybank.hr.*;
public class NewHRAccount extends HRAccount{
       protected String name;
       
        public static void main(String[] args) { }
}

//In file HRAccount.java
package com.mybank.hr;
import com.mybank.accts.*;
import com.mybank.newhr.*;
public class HRAccount extends Account{
      public static void main(String[] args){
                 NewHRAccount newHRAcct = new NewHRAccount();
                 newHRAcct.acctId = "111"; //will this compile?
                 newHRAcct.name = "John"; //will this compile?
       }
}

The com.mybank.newhr causes Error: Could not find or load main class. when I introduce extends HRAccount!

Does this have anything to do with the fact that the imports between these two packages are reciprocal? If not, why all of a sudden on this particular extends?

Thanks

p.s. I tested on both command line and netbeans, just in case

[admin]

Compiles and runs fine. After commenting out newHRAcct.acctId = "111"; newHRAcct.name = "John"; of course but other than that no issue.

Check out section 1.8 "Compiling multiple source files at once." Use the -classpath option.

[OCAJO1]

This is somewhat strange. Well, maybe not.

Although package com.mybank.newhr; only had imported com.mybank.hr.*;, it had to also know the path for com.mybank.accts.*;. I guess because com.mybank.hr.*; imported com.mybank.accts.*; to begin with.

If above is indeed the reason that com.mybank.newhr; could not compile before, it looks like java needed to be told of import based chain-file directory location, although the 3rd package did not import the 1st package directly.

[OCAJO1]

Question,

Since import is really nothing more than telling the compiler where to find something, I wonder why they did not give java the capability to backtrack using import chain to find the location of files holding classes (interfaces, enums) that are being extended/implemented?

For example, If A is being extended by B and B is being extended by C, why shouldn't java be able to backtrack from C using the imports, to find out where the files holding A and B classes are located?

[admin]

Classic case of faulty premise leading to problematic inference. "Since import is really nothing more than telling the compiler where to find something", where did you read this? The classpath option is for telling the compiler where to find something, not the import statement! Check out 2.4 for details.


BTW, two things - 1. A class may not necessarily reside in a file by the same name. 2. Location of a .java file has nothing to do with the location of a class file. You can keep a java file anywhere you like. So, how will the compiler know where have you kept the java file just by looking at the import statements?

[Username987654]

That is why HTAccount class is allowed to access HRAccount object’s acctId field but is not allowed to access Account object’s acctId field

should be

That is why HRAccount class is allowed to access HRAccount object’s acctId field but is not allowed to access Account object’s acctId field

?

[admin]

Yes. Should be fixed.

[OCAJO1]

Classic case of faulty premise leading to problematic inference. "Since import is really nothing more than telling the compiler where to find something", where did you read this? The classpath option is for telling the compiler where to find something, not the import statement! Check out 2.4 for details.


BTW, two things - 1. A class may not necessarily reside in a file by the same name. 2. Location of a .java file has nothing to do with the location of a class file. You can keep a java file anywhere you like. So, how will the compiler know where have you kept the java file just by looking at the import statements?

This is from sec 2.4.1

Note:
The word"\import" is really a misnomer here. The import statement doesn't import anything
into your class. It is merely a hint to the compiler to look for classes in the imported package.
You are basically telling the compiler that the simple class names referred in this code are
actually referring to classes in the packages mentioned in the import statements. If the
compiler is unable to resolve a simple class name (because that class is not in the same
package as this class), it will check the import statements and see if the packages mentioned
there contain that class. If yes, then that class will be used, if not, a compilation error will
be generated.

Did I over interpret the underlined sentences in the Note, by mangling the classpath into import?

[admin]

Yes, I think you are misinterpreting. The key part of the para is "look for classes in the imported package". This has nothing to do with classpath, files, or location of files.

[Username987654]

now free to manage acctIt in its own way

should be

now free to manage acctId in its own way

?

[admin]

Correct.
thank you for your feedback!