File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Kind Attn:Marcus Green - Pl. clear doubt Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Kind Attn:Marcus Green - Pl. clear doubt" Watch "Kind Attn:Marcus Green - Pl. clear doubt" New topic

Kind Attn:Marcus Green - Pl. clear doubt

Praveen Kumar
Ranch Hand

Joined: Jul 27, 2000
Posts: 31
Exam 1
Question 58)

You have these files in the same directory. What will happen when you
attempt to compile and run if you have not already compiled
package Base;
class Base{
protected void amethod(){
}//End of amethod
}//End of class base
package Class1;
public class Class1 extends Base{
public static void main(String argv[]){
Base b = new Base();
}//End of main
}//End of Class1
1) Compile Error: Methods in Base not found
2) Compile Error: Unable to access protected method in base class
3) Compilation followed by the output "amethod"
4)Compile error: Superclass Class1.Base of class Class1.Class1 not

Ans: 4)Compile error: Superclass Class1.Base of class Class1.Class1
not found
Using the package statement has an effect similar to placing a source
file into a different directory.
Because the files are in different packages they cannot see each
other. The stuff about File1 not
having been compiled was just to mislead, java has the equivalent of
an "automake", whereby if it
was not for the package statements the other file would have been
automatically compiled.

According to RHE (Java 2) Page No.183 last two lines "It is illegal for a package and a class to have the same name."
So IMO there is no question to check about " Superclass Class1.Base of class Class1.Class1 not found". because compiler will check first about same name of package and class and will
show compiler error.what would be better than this if Marcus read this and explain.because i think the answer " compile
error" is ok but this is not for "Superclass Class1.Base of class
Class1.Class1 not found".

Praveen Kumar
Mumbai ,India

Praveen Kumar<BR>Mumbai ,India<BR>email:
Ajith Kallambella

Joined: Mar 17, 2000
Posts: 5782
This is an interesting bug. Here I am producing some excerpts from my notes and Sun's Bug parade -
JLS says that a package and a class cannot have the same fully qualified name, at least if the name is itself qualified. The compiler does not always check for such a state of affairs. It should probably be more thorough, looking for a package whenever it discovers a (non-nested) class.

The scenarios here are
1) Top level package containing a class with the same name.
A class in the highest package level ( myFineClass ) can have a class named the same ( myFineClass ). JDK versions prior to 1.1 gave a compilation error even in this case, but interestingly the later versions started to accept this kind of code. This was logged as a bug and was closed by Sun with the comment - So JLS 1.1 section is no longer correct for 1.1, and this is not considered a compiler bug.
2) A subpackage containing a class with the same name.
A sub-package( mypackage.myclass ) cannot have a class name identical to the package name( my class ). The compiler gives an ambiguity error.
The compiler did not properly implement this restriction in 1.0.2, but it was never allowed by the specification. The specification has not changed, but the compiler is now closer to the specification by implementing the restriction on package "import X.*" statements.
This is an area where the compiler is weak. If you are interested to learn more about this, checkout bug numbers 4027499,4051041 in Bug Parade
Hope this clears the confusion


Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
I agree. Here's the link:
subject: Kind Attn:Marcus Green - Pl. clear doubt
It's not a secret anymore!