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.
[HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Moderator: admin
-
- Posts: 95
- Joined: Sat Dec 26, 2015 6:37 pm
- Contact:
[HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
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:
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Thank you
If you like our products and services, please help us by posting your review here.
-
- Posts: 221
- Joined: Mon Nov 26, 2018 2:43 pm
- Contact:
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
When I setup the second set of examples,
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
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?
}
}
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
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
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.
Check out section 1.8 "Compiling multiple source files at once." Use the -classpath option.
If you like our products and services, please help us by posting your review here.
-
- Posts: 221
- Joined: Mon Nov 26, 2018 2:43 pm
- Contact:
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
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.
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.
-
- Posts: 221
- Joined: Mon Nov 26, 2018 2:43 pm
- Contact:
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
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?
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?
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
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?
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?
If you like our products and services, please help us by posting your review here.
-
- Posts: 95
- Joined: Sat Dec 26, 2015 6:37 pm
- Contact:
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
should beThat is why HTAccount class is allowed to access HRAccount object’s acctId field but is not allowed to access Account object’s acctId field
?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
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Yes. Should be fixed.
If you like our products and services, please help us by posting your review here.
-
- Posts: 221
- Joined: Mon Nov 26, 2018 2:43 pm
- Contact:
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
This is from sec 2.4.1admin wrote: ↑Fri Feb 15, 2019 9:03 pmClassic 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?
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?
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
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.
If you like our products and services, please help us by posting your review here.
-
- Posts: 95
- Joined: Sat Dec 26, 2015 6:37 pm
- Contact:
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
should benow free to manage acctIt in its own way
?now free to manage acctId in its own way
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: [HD Pg 263, Sec. 8.4.3 - understanding-protected-access]
Correct.
thank you for your feedback!
thank you for your feedback!
If you like our products and services, please help us by posting your review here.
Who is online
Users browsing this forum: No registered users and 19 guests