• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

Kind Attn:Marcus Green - Pl. clear doubt

 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Exam 1
Question 58)

You have these files in the same directory. What will happen when you
attempt to compile and run
Class1.java if you have not already compiled Base.java
//Base.java
package Base;
class Base{
protected void amethod(){
System.out.println("amethod");
}//End of amethod
}//End of class base
package Class1;
//Class1.java
public class Class1 extends Base{
public static void main(String argv[]){
Base b = new Base();
b.amethod();
}//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
found

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
email: [email protected]
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Praveen,
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 6.5.4.2 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

Ajith
 
reply
    Bookmark Topic Watch Topic
  • New Topic