• 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:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

Use of pubilc methods in package class

 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all !
I don't know whether u may have a direct question related to the following in SCJP, but I guess it may helpful in getting some your concepts clear for the SCJP:
Sometime back I had posted 2 question asking (but got no explanation for them),
1) what is the use of having public methods in a package access level class? If a class has package only access, that means we can't access it outside the package. If so, why do we need public access for that method? It could just been left as default access?
i.e.
class PackageOnly
{
public PublicMethod(){} // How can we access this outside?
}
Well, after some hunting, i found the an excellent explanation in JLS. So, I felt I could share with you all. Here it goes:

8.2.1.4 Accessing Members of Inaccessible Classes
===================================================
Even though a class might not be declared coderanch, instances of the class might be available at run time to code outside the package in which it is declared if it has a
public superclass or superinterface. An instance of the class can be assigned to a variable of such a public type. An invocation of a public method of the object
referred to by such a variable may invoke a method of the class if it implements or overrides a method of the public superclass or superinterface. (In this situation,
the method is necessarily declared coderanch, even though it is declared in a class that is not coderanch.)
Consider the compilation unit:
package points;
public class Point {
public int x, y;
public void move(int dx, int dy) {
x += dx; y += dy;
}
}
and another compilation unit of another package:
package morePoints;
class Point3d extends points.Point {
public int z;
public void move(int dx, int dy, int dz) {
super.move(dx, dy); z += dz;
}
public void move(int dx, int dy) {
move(dx, dy, 0);
}
}
public class OnePoint {
public static points.Point getOne() {
return new Point3d();
}
}
An invocation morePoints.OnePoint.getOne() in yet a third package would return a Point3d that can be used as a Point, even though the type Point3d is
not available outside the package morePoints. The two argument version of method move could then be invoked for that object, which is permissible because
method move of Point3d is public (as it must be, for any method that overrides a public method must itself be coderanch, precisely so that situations such as this
will work out correctly). The fields x and y of that object could also be accessed from such a third package.
While the field z of class Point3d is coderanch, it is not possible to access this field from code outside the package morePoints, given only a reference to an instance
of class Point3d in a variable p of type Point. This is because the expression p.z is not correct, as p has type Point and class Point has no field named z; also,
the expression ((Point3d)p).z is not correct, because the class type Point3d cannot be referred to outside package morePoints.
The declaration of the field z as public is not useless, however. If there were to be, in package morePoints, a public subclass Point4d of the class Point3d:
package morePoints;
public class Point4d extends Point3d {
public int w;
public void move(int dx, int dy, int dz, int dw) {
super.move(dx, dy, dz); w += dw;
}
}
then class Point4d would inherit the field z, which, being coderanch, could then be accessed by code in packages other than morePoints, through variables and
expressions of the public type Point4d.
=============================================================
2) The second question I asked was:
Consider the following.
When declaring an interface:
Interface I1
{
void PackageAccessMethod(); // Here it is default access
}
class Test implements I1
{
// Here we have to specify explicitly public else compiler error
public void PackageAccessMethod()
{---- some code----}
}
In the class Test, if we do not give the access specifier as public then we get a compiler error. I did not understand why this was happening: On agaoin JLS came to helped me out.
JLS clearly says that all the methods declared in an interface are IMPLICITLY PUBLIC!! That's is why we have to implement in a class as PUBLIC !
Also, all interfaces are IMPLICITLY ABSTRACT! And this modifier is obsolete mow and must not be used.
People , I understand that this is an awfully long posting, but I simply could not resist to share this piece of info with you ppl coz they had been bugging me for a long time and nobody seemed to give me a good explanation. Now, I feel extremly relieved.
Sorry, about this in case you had these concepts clear already.
Thanks,
Sampaths77

 
Ranch Hand
Posts: 3141
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ... Thanks for the post. I've also been confused by why you'd declare a method public in a package class.
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am quite relieved to hear that atleast there is someone else who had a similar confusion as me and had it cleared.
Since, nobody responded to this post, I felt very silly that I was the only one in the world to get these kind of doubts. Now, I don't feel like that anymore- )
-sampaths77

 
Jane Griscti
Ranch Hand
Posts: 3141
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi samppaths,
There's nothing silly about doubts, everyone gets them, think they're embedded in the structure of the Universe why else would we have Heisenbergs<sp?> Uncertainty priniciple
 
reply
    Bookmark Topic Watch Topic
  • New Topic