Reg. Packages

[Angela Narain]

What happens when you attempt to compile and run these two files in the same directory?
//File P1.java
package MyPackage;
class P1{
void afancymethod(){
System.out.println("What a fancy method");
}
}
//File P2.java
public class P2 extends P1{
afancymethod();
}
1) Both compile and P2 outputs "What a fancy method" when run
2) Neither will compile
3) Both compile but P2 has an error at run time
4) P1 compiles cleanly but P2 has an error at compile time

The correct answer is 4)
Can someone explain to me the question " two files in the same directory" w.r.t to the package
structure.
If i make the following change in // File P2.java :

import MyPackage.P1
public class P2 extends P1{
afancymethod();
}

I donot think the code will still compile.
We have to make class P1 as public and declare
the method afancymethod() also public.
Am i right ?

[Jose Botella]

Default access, the one that they get if none specified, allows access whithin the same package, so you are not right.

[Cameron Park]

Angela, you need to decalre both P1 and afancymethod public. Having only default access, P2 has no access to them whatsoever.

[Jose Botella]

In fact in each directory there are two packages:
the one with the same name as the directory and the one with no name at all (deafult package). They are different packages, even the default packages through several directories are different.

[Jane Griscti]

Hi Jose,
Just an FYI:
There is one default package per directory which basically means that any files in the directory are treated as if they had a package name that matched the directory name.
Only one default package, the one related to the current directory, is visible.
Angela,
The P2 file won't compile correctly when it's in the same directory as P1, even if they are in the MyPackage directory, as, when you use a package statement, the class name includes the package name. For example, the fully qualified name of the P1 class is "MyPackage.P1".
If you try to import P1 in P2, you'll still have a problem because the compiler will look for P1 in a subdirectory called "MyPackage" using the current directory as the starting point for the subdirectory search.
Hope that helps.

------------------
Jane Griscti
Sun Certified Programmer for the Java� 2 Platform
[This message has been edited by Jane Griscti (edited September 15, 2001).]

[Jose Botella]

Hi Jane Thanks for answering
I guess FYI means for yor information.
>There is one default package per directory which basically means >that any files in the directory are treated as if they had a >package name that matched the directory name.
If this were the case don't you think that P2 would have been able to use P1? Because P2 is in the same directory that P1, it would have a package name like MyPackage, and it would have acces to P2.
I thought that the classes whithin a compilation unit are only part of a package if there is a leading package sentence in it.
I think that the default package is compound of the java files without a package sentence. So classes in the default package has a simple name, with no packages names.
Please correct me if wrong.

[Marilyn de Queiroz]

P1 compiles to < defaultDirectory\MyPackage > and P2 compiles to < defaultDirectory >
Since P1 has no access modifier and therefore has "package" access, P2 cannot see P1. They are not in the same directory. Therefore they are not in the same package.
Since P2 is public, P1 can see P2 with no problem.

[This message has been edited by Marilyn deQueiroz (edited September 16, 2001).]

[Jane Griscti]

Hi Jose,

If this were the case don't you think that P2 would have been
able to use P1? Because P2 is in the same directory that P1, it
would have a package name like MyPackage, and it would have acces to P2.

No. As Marilyn pointed out when P1 is compiled it's fully qualified name is "MyPackage.P1". In the code example, "P2 extends P1" ... the compiler will search for a class named "P1" not "MyPackage.P1".
You can check this for yourself by using javap.exe to decompile the P1 class file:
<pre>
C:\Java\Examples\MyPackage>javap -c P1.class
Error: Binary file 'P1' contains MyPackage.P1

</pre>
"P2" would not compile to "MyPackage.P2" it would only compile to "P2". The package name only becomes part of the fully qualified name if a package statement is used.
To see this, create a third file:
<pre>
//File P3.java
public class P3{
void afancymethod(){
System.out.println("What another fancy method");
}
}

</pre>
Compile it in the MyPackage directory and decompile using javap; you can see that the fully qualified class name is P3. The directory name is not part of the class name.
<pre>
C:\Java\Examples\MyPackage>javap P3
Compiled from P3.java
public class P3 extends java.lang.Object {
public P3();
void afancymethod();
}

</pre>
Look at P1 again and you see:
<pre>
C:\Java\Examples>javap MyPackage.P1
Compiled from P1.java
public class MyPackage.P1 extends java.lang.Object {
public MyPackage.P1();
void afancymethod();
}
</pre>
In this case, the package statement becomes part of the fully qualified name. The package name correlates to the directory structure meaning the compiler, when searching for the class, will first look for a subdirectory called "MyPackage" and then a "P1.class" file within that directory. It uses the current directory as the starting point for the search (unless you've set up a classpath, in which case is will use the last directory in the the classpath as the starting point for the search)

I think that the default package is compound of the java files
without a package sentence. So classes in the default package has
a simple name, with no packages names.

I think that's partly right. The default package isn't a "compound name"; it's just the current directory or the last directory listed in the classpath. You are right that if no package statement is used the fully qualified name and the simple name would be the same.
Hope that helps.
------------------
Jane Griscti
Sun Certified Programmer for the Java� 2 Platform