what is right....and why???

[Amit Das]

hi all,

plz help find the correct answer with an appropriate reason...

  
public class Bofa
{ 
    Bofa() 
    { 
    } 
}

Select the correct statements.



A. The class Bofa can be referenced outside the package in which it is defined.

B. The class Bofa cannot be instantiated outside the package in which it is defined.

C. The class Bofa cannot be extended outside the package in which it is defined.

D. The class Bofa can be referenced, instantiated or extended anywhere.

E. The above code will cause a compiler error. The constructors of public class have to be public.

Options

A, B, D
A, B, C
A, B, E
B, C, D
B, C, E

thanx,
amit

[Srinivasa Raghavan]

Ans : A B C
A : Since the class is public
B,c : Since the constructor has a default access

[ March 23, 2005: Message edited by: Srinivasa Raghavan ]
[ March 23, 2005: Message edited by: Srinivasa Raghavan ]

[Swapan Mazumdar]

Originally posted by Srinivasa Raghavan:
Ans : A B C
A : Since the class is public
...

Can you please try to illustrate with an example where you are practically referring to this subject(class) from outside the package.

-Swapan

[Srinivasa Raghavan]

package mypack1;
public class Bofa{ Bofa() { } }

package mypack2;
import mypack1.*;
public class Bofa1{
Bofa1(){ }
public static void main(Stirng [] a )
{
Bofa b = new Bofa()
}
}

[Parameswaran Thangavel]

hi
if a class is a public then the constructor will be automatically have public modifier.

to my knowledge
the class can be extended any where (through import statement)
it can also instantiate and referenced any where.

[Ernest Friedman-Hill]

Srinivasa Raghavan's code will not compile. Bofa's constructor is not public, so it can not be instantiated outside of the package it's defined in. And Parameswaran Thangavel's statement is untrue; it's absolutely possible -- and common -- to have public classes with non-public, even private, constructors. Two prominent examples of public classes with private constructors are the java.lang.System class, which you can therefore reference, but not construct, outside of the package they're defined in.

As to a concrete example of referencing Bofa outside of its package: here's one in which a public method in package1 returns an instance of Bofa, and a class in package2 uses it to get an instance of Bofa -- even though package2 can't use "new Bofa()" directly.

package mypack1;
 
public class Bofa{
  Bofa() {}
}
 
public class BofaFactory {
  public static Bofa get() {
    return new Bofa();
  }
}
 
package mypack2;
import mypack1.*;
 
public class Example{
  public static void main(String[] args) {
    Bofa b = BofaFactory.get();
  }
}

[Srinivasa Raghavan]

Hi Ernest,

I just want to point out the second option is true

B. The class Bofa cannot be instantiated outside the package in which it is defined

Hence the code.

[Parameswaran Thangavel]

And Parameswaran Thangavel's statement is untrue; it's absolutely possible -- and common -- to have public classes with non-public, even private, constructors

hi
i didn't say that public class can't have the private constructor.
my point is when a access modifier is not specified for the constructor then it will take the access modifier defined for the class.

since the class is public and the access modifier for the const is not given it will take the class modifier which is "public".so it can be instantiated and referenced outside the package this is my Point.

any comment???

[Animesh Shrivastava]

Parameswaran,

since the class is public and the access modifier for the const is not given it will take the class modifier which is "public".

have u tried out this in ur code?
Just do it, u will know the result.
If u explicitly define a constructor the access sprecifiers what u specify will be its specifier. If u have not given any specifier it will be taken as the default. But remember the implicit default constructor is always public.

[Parameswaran Thangavel]

hi animesh
can i tell that when a constructor is defined explicitly without any modifier then it will be default access modifier.
if we didn't define any constructor explicitly then the access modifier for the default constructor will be of class type.in our case it will be of public.

am i correct.

[Swapan Mazumdar]

Originally posted by Animesh Shrivastava:
...if u explicitly define a constructor the access sprecifiers what u specify will be its specifier. If u have not given any specifier it will be taken as the default. But remember the implicit default constructor is always public.

I am with Animesh(nice name) because I have read this in K & B.
Now guys what is the correct answer(s) for the initial post

-Swapan

[Srinivasa Raghavan]

Ans : A B C
A : Since the class is public
B,c : Since the constructor has a default access

[Ajay Bhargov]

Hi Srinivasa,

Can u just explain to me as to why the class cant be extended outside the package..

Do u mean tht even though the class is public, since it has a default constructor it cant be extended??

Plz do reply to my post.

[Srinivasa Raghavan]

Because the constructor of the super class is not public.

PS: In the first post the constructor is not the default constructor.
The default constructor is the one inserted by JVM it has the same access modifier that the class have.
[ March 24, 2005: Message edited by: Srinivasa Raghavan ]

[prajkta patil]

hi guys i am with Parameswaran Thangavel bcause what he have written is 100% true.by default constructor have the same access modifier as that of its class.read the book carefully.

[Tony Morris]

The implicit [sic] constructor is not always public.

It is called the Default Constructor and is covered in Java Language Specification 8.8.7.

As an aside, an explicit no-argument constructor is often referred to as a "Default Constructor", but this is erroneous.

[prajkta patil]

hi tony,
i have not written default constructor in my explanation .i have written
"By default(if u didn't specify any acess modifier for cons), the constructor will have same access modifier as the class."

[Srinivasa Raghavan]

So what is teh final answer for that question.

[ankur rathi]

Originally posted by Animesh Shrivastava:
But remember the implicit default constructor is always public.

implicitly default constructor is not always public , it takes access specifier of class .

[prajkta patil]

oh no,
after reading rathiji's post i got confused then i searched about this in the book.in book of k&b ,it is written
"The default constructor has the same access modifier as the class."
means what i have written earlier is wrong? i was thinking "By default,the constructor has the same access modifier as the class."
but according to book i guess it is not about "by default",it is about "the default constructor".& rathi ji also says same.
i think we need to run the prgs then only we can get the correct answer.

[Pete Knecht]

Originally posted by Srinivasa Raghavan:
So what is teh final answer for that question.

The final answer will be A,B,C. Test it if you wish.

It's been said a few times here, but since Bofa has a constructor, a default constructor won't be added. The constructor as given in the original Bofa class has default (or package) access, so it won't instantiate outside the package.

If the class had read:
public class Bofa { }

then a default constructor would've been compiler-added and given the same access as the class, i.e., public.

[Parameswaran Thangavel]

hi Knecht
can i say that to extend and instantiate the class outside its package the class should have its constructor public

to have the reference outside its package its enough to have the public class (don't need worry about the constructor it can be private)

[Pete Knecht]

I should've added my last post that the reason that answer C fails is less clear to me. And it will fail: if you try to extend Bofa from outside its package you get a compiler error having to do w/ the package access currently on Bofa's constructor.

But this point doesn't seem very intuitive to me. Constructors can't be inherited...so, wait, if we try to extend the public class Bofa outside its package, and its constructor is not inherited, then isn't that like the extended Bofa not having a constructor at all, and thus a default constructor having public access should be given to the new, extended class? Apparently not, since a compiler error is given. Again, I only mention this point by way of saying that why C fails is not intuitive to me.

[Animesh Shrivastava]

By Peter,

Constructors can't be inherited...so, wait, if we try to extend the public class Bofa outside its package, and its constructor is not inherited, then isn't that like the extended Bofa not having a constructor at all, and thus a default constructor having public access should be given to the new, extended class?

The main intention of having such kinda desgin is that no class, outside the package in which the class resides, should be able to create the object of such a class, here this kind of class is Bofa. But u can still inherit the class's members and invoke them from ur subclass.

By Rathi,

implicitly default constructor is not always public , it takes access specifier of class .

Yeah i guess i was wrong, i am looking into it. As far as i have heard class always gets a implicit public default constructor. Hmmm but whats the use of implicit public default constructor if the class itself is not public.

[Pete Knecht]

Originally posted by Parameswaran Thangavel:
hi Knecht
can i say that to extend and instantiate the class outside its package the class should have its constructor public

to have the reference outside its package its enough to have the public class (don't need worry about the constructor it can be private)

Hi....
The way I'm understanding your reply here (and the original problem), I think the answer to both of your questions is "yes". The way Bofa is now, we can't instantiate or extend it outside of its package.

But since it's public, we should be able to refer to it from another package (if it's already compiled there and thus constructed, then its private constructor won't even come into play in this case, right?)

Actually, I'm glad I stumbled onto this post.
Subtle variation and problem:
Take Bofa the way it is now, and add an overloaded constructor, say,
public Bofa(String s){}

Note the public access. Now can we extend and instantiate Bofa outside of its package, *if we use the overloaded constructor*? Say, with,

package other-than-Bofas;
import package-that-contains-Bofa;
class TestBofa
{ public static void main(String[] args)
{ Bofa b = new Bofa("Some String"); }
}

I'm going to guess and say yes, this will compile, but I don't know......

[prajkta patil]

thanks rathi ji & Pete Knecht ,
i have tried.correct answer is A B C.
thanks a lot...

[Pete Knecht]

Originally posted by Pete Knecht:


(A) But since it's public, we should be able to refer to it from another package (if it's already compiled there and thus constructed, then its private constructor won't even come into play in this case, right?)

(B) Actually, I'm glad I stumbled onto this post.
Subtle variation and problem:
Take Bofa the way it is now, and add an overloaded constructor, say,
public Bofa(String s){}

Note the public access. Now can we extend and instantiate Bofa outside of its package, *if we use the overloaded constructor*? Say, with,

package other-than-Bofas;
import package-that-contains-Bofa;
class TestBofa
{ public static void main(String[] args)
{ Bofa b = new Bofa("Some String"); }
}

I'm going to guess and say yes, this will compile, but I don't know......

I reply to myself (sort of). On point A above. I expressed that in a really confused way. The answer is still, yes, you can refer to Bofa outside its package b/c it's public. For instance, suppose Bofa had a static member, say a String,
public static String sBofa = "From the Bofa class";

You could then access this sBofa string from another package with:
Bofa.sBofa (b/c the string is static). You'd need to get at the static member thru Bofa being public.

On point B:
Yes, it works. If you add to the original Bofa *another public, overloaded* constructor, say:
public Bofa(String s){}

then you can indeed instantiate Bofa from another package with, say:
Bofa b = new Bofa("String for the overloaded constructor");

SO, even though Bofa has a package level no-arg constructor, you can instantiate a version using the overloaded constructor above. That does make some intuitive sense, as the no-arg constructor is just by-passed here altogether.

[Pete Knecht]

Originally posted by Animesh Shrivastava:
The main intention of having such kinda desgin is that no class, outside the package in which the class resides, should be able to create the object of such a class, here this kind of class is Bofa. But u can still inherit the class's members and invoke them from ur subclass.

Animesh,
I'm still missing something here(I think) regarding inheritance and this package access constructor of Bofa. If we go outside the package, we can't extend Bofa. The following gives an error:
class NewBofa extends Bofa{ }

The error arises from Bofa's constructor having package access (and worse, presumably, private, access). So, in line with what you say above, we won't be able to get the benefit of the other members of Bofa by extending unless the constructor is changed to public, or protected, right? But then we'll also be able to instantiate Bofa, contra to what you say above.

SO, under what configuration does what you say above hold? When Bofa's constructor is private, and the extension is attempted from within the same package as Bofa? I'm not trying to be difficult Just trying to get clear on a bunch of issues this question about constructor access seems to have raised (at least for me).

[Animesh Shrivastava]

Pete,
U r right, i was wrong in pointing that out.
But if suppose u have static methods out there, then i hope thats like saying
U cannot extend the class nor instantiate from outside the package but u can call static methods on it, right? like Math Class ( but its having final modifier)

[Pete Knecht]

Originally posted by Animesh Shrivastava:
Pete,
U r right, i was wrong in pointing that out.
But if suppose u have static methods out there, then i hope thats like saying
U cannot extend the class nor instantiate from outside the package but u can call static methods on it, right? like Math Class ( but its having final modifier)

Animesh,
Well, you were partially correct, actually.
There's a whole set of issues that this thread seems to have morphed into. And, actually, I'm not sure it's explicitly covered in the Sierra/Bates book (I'll have to check the book again, so don't crucify me if it's there but I've just forgotten it )

The issue is simply this:
How does the access modifier of a constructor affect the instantiation and extension of a class both from within its own package and from the outside? Turns out, there's more here than I have previously thought about, and it's not altogether that intuitive.

I've been playing around, and here's a short answer to what I've found:

Start with 2 classes in the same package:
public class A{
A() { }
}

class B extends A{ }

NOW, the constructor on A has package access, and there will be no error. B can extend A just fine. In fact, if A's constructor has public, protected, or default access status, there is no problem w/ the extension. BUT, if A's constructor is private, B *cannot* extend A. That's an important point I didn't realize before.

NOW, take the same class A (in one package), BUT imagine we are trying to extend and instantiate it from within another package. Here's where it gets tricky. (Further imagine the proper import statement has been made to import A in this other package.) There are two issues here, instantiating A and extending A from this other package.

Extending A:
From this other package, the line,
class B extends A { }

will only work *if the constructor in A* has public or protected status. In the original Bofa class way back, the constructor only had package access, and that was what was causing the extension problems outside its package.

Instantiating A:
(Remember, we're outside A's package here still.) The line,
A a = new A();

will not compile, because although the class A has public access, its constructor only has package access. In fact, A cannot be instantiated like this in another package if its constructor has anything less than public access (protected won't work; and package and private certainly won't).

SO, if you've followed this, you can see that the access on A's constructor affects instantiation and inheritance in other packages *differently*, with instantiation demanding that the constructor be public, while extension only requires that A's constructor be public or protected (again, assuming you are doing these two outside of A's original package.)

Whew. I think I've got this right now. This whole thing was spawned from why answer C in the original post above is true. The effects of this constructor access are slippery.

And going back to what you said, if I am right in the above, then we could have the following situation regarding the prevention of instantiation while still allowing inheritance:
Let A's constructor have protected access status. Then, from *another* package, we won't be able to instantiate A, but we *will* still be able to inherit from it, as in,
class B extends A { }

I think that's the only status A's constructor can have while having the inheritance/non-instantiating goal (from between two packages like in the above.)
[ March 31, 2005: Message edited by: Pete Knecht ]

[Shivakanth Thyagarajan]

Hi Pete,
thanks for this extended reply, Please give an valid reason why Answer A is correct. I am unable to grasp it. The reason being the class Bofa cannot be extended or instantiated outside it's current package. Now if we reference it outside the package what values that reference could hold. Will that reference will serve any purpose.

Thanks
Shiva

[Parameswaran Thangavel]

hi Knecht

i putting in different words now

instantiating the class

1) outside package

--the constructor must be public

2)within the same package

--constructor can be protected or default or public

to reference the class

1)outside package
--the class must be public (no need to care about the constructor)


2)within the same package
--the class can be public or default access


please reply me

[Pete Knecht]

Originally posted by Shivakanth Thyagarajan:
Hi Pete,
thanks for this extended reply, Please give an valid reason why Answer A is correct. I am unable to grasp it. The reason being the class Bofa cannot be extended or instantiated outside it's current package. Now if we reference it outside the package what values that reference could hold. Will that reference will serve any purpose.

Thanks
Shiva

Hi,
A is correct simply because Bofa is public. So a class from another package can reference it. The reference will have purpose even if we can't instantiate it b/c what if there are static members, f.e., in Bofa? We would still want Bofa to be public so we could access those members. Also, answer A is independent of the access modifier on Bofa's constructor.

When you say, "The reason being the class Bofa cannot be extended or instantiated outside it's current package", be careful. The way Bofa is now, with package access on the constructor, that's true. Changing the access on the constructor could change all that, tho.

[Pete Knecht]

Originally posted by Parameswaran Thangavel:
hi Knecht

i putting in different words now

instantiating the class

1) outside package

--the constructor must be public

2)within the same package

--constructor can be protected or default or public

to reference the class

1)outside package
--the class must be public (no need to care about the constructor)


2)within the same package
--the class can be public or default access
please reply me

Parameswaran,
Yes, this is I think a correct summary of what I meant in my long post above, except you didn't add the part about extending the class, which is the tricky part. Within the same package, you can extend as long as Bofa's constructor is public, protected, or package. Outside the package, you can extend Bofa as long as its constructor is public or protected (that makes sense, protected means access within the same package or to subclasses.)

Note that if Bofa's (or what I called class A) constructor is protected, you won't be able to instantiate it outside the package. The above implies this, but it's worth explicitly mentioning. It also makes sense--the protected modifier lets subclasses have access, but with a pure instantiation there would be no subclassing.