Page 1 of 1
[HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Thu Jan 03, 2019 11:55 am
by 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.
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Fri Jan 04, 2019 8:46 am
by admin
Thank you
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Tue Feb 12, 2019 7:50 pm
by 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
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Tue Feb 12, 2019 9:56 pm
by 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.
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Wed Feb 13, 2019 3:36 pm
by 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.
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Fri Feb 15, 2019 1:17 pm
by 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?
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Fri Feb 15, 2019 9:03 pm
by 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?
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Sat Feb 16, 2019 12:01 am
by 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
?
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Sat Feb 16, 2019 2:46 am
by admin
Yes. Should be fixed.
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Sat Feb 16, 2019 4:51 pm
by OCAJO1
admin wrote: ↑Fri Feb 15, 2019 9:03 pm
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?
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Sat Feb 16, 2019 7:38 pm
by 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.
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Thu May 16, 2019 9:25 am
by Username987654
now free to manage acctIt in its own way
should be
now free to manage acctId in its own way
?
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Posted: Thu May 16, 2019 9:33 pm
by admin
Correct.
thank you for your feedback!