Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / June 2007

Tip: Looking for answers? Try searching our database.

FINAL keyword

Thread view: 
kaja_love160@yahoo.com - 20 Jun 2007 23:21 GMT
hello

1)
If method ( call it U ) in parent class is made private, then methods
of child class can’t access U directly, but they still inherit this
private method U.
Is it similar situation if  parent method ( call it U1 ) is declared
final  Meaning child methods can’t access U1 directly, but they still
inherit it?

2)
Subclass can override parent’s class method by creating method with
same name and same parameter list --> this is not true if parent
method is declared private
So if compiler identifies a method by its name and its parameter list,
then why do we get compile-time error if “hey()” in B is private
( compiler informing us that “hey()” can’t be overriden ):

class A{

    private final void hey(){…}

}

class B extends A{

            private void hey(){…}
}

, while compiler doesn't complain when “hey()” in class B is made
public:

class A{

    private final void hey(){…}

}

class B extends A{

             public void hey(){…}
}

? That would suggest that when it comes to overriding method, java
doesn’t only distinguish between methods by their name and parameter
list, but also by their access modifier.

thank you
Lew - 21 Jun 2007 00:25 GMT
> 1)
> If method ( call it U ) in parent class is made private, then methods
> of child class can’t access U directly, but they still inherit this
> private method U.

No.
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.8>
> A class C inherits from its direct superclass and direct superinterfaces all non-private methods (whether abstract or not) of the superclass and superinterfaces that are public, protected or declared with default access in the same package as C and are neither overridden (§8.4.8.1) nor hidden (§8.4.8.2) by a declaration in the class.

Also, methods don't inherit methods anyway, classes do.

> Is it similar situation if  parent method ( call it U1 ) is declared
> final  Meaning child methods can’t access U1 directly, but they still
> inherit it?

No.  "final" (not "FINAL" as in your subject, because that's not a keyword)
does not mean "child methods can’t access [it] directly", and methods don't
inherit methods anyway.  Classes inherit methods.

"final" does not control accessibility, only overridability.

> 2)
> Subclass can override parent’s class method by creating method with
> same name and same parameter list --> this is not true if parent
> method is declared private

Correct so far.

> So if compiler identifies a method by its name and its parameter list,
> then why do we get compile-time error if “hey()” in B is private
> ( compiler informing us that “hey()” can’t be overriden ):

What is the error message?  What is the actual code?  Provide an SSCCE!

I cannot get any kind of error message from an attempt to "override" a private
method, final or not.  Perhaps because it's not illegal?

> class A{
>
>      private final void hey(){…}
>
> }

This code doesn't compile.

>  class B extends A{
>
>              private void hey(){…}
> }

This code doesn't compile.

>  , while compiler doesn't complain when “hey()” in class B is made
> public:
[quoted text clipped - 13 lines]
> doesn’t only distinguish between methods by their name and parameter
> list, but also by their access modifier.

Perhaps, if your facts were correct.  My SSCCE didn't give anything like the
error you hinted about.
> Compiling 1 source file to projects/testit/build/classes
> compile:
> run-single:
> Parent.privFinal()
> Parent.priv()
> BUILD SUCCESSFUL (total time: 3 seconds)

<sscce comment="this code compiles and runs without compiler error"
       source="testit/Child.java" >
/** Child.java
 */
package testit;

class Parent
{
    private final void privFinal()
    {
        System.out.println("Parent.privFinal()");
    }
    private void priv()
    {
        System.out.println("Parent.priv()");
    }
    public final void invoke()
    {
        privFinal();
        priv();
    }
}

/** Child .
// warning: "Exporting non-public type through public API" from IDE.
 */
public class Child extends Parent
{
    private void privFinal()
    {
        System.out.println("Child.privFinal()");
    }
    private void priv()
    {
        System.out.println("Child.priv()");
    }
    public static void main( String [] args )
    {
        Parent child = new Child();
        child.invoke();
    }
}
</sscce>

It compiles, it runs, it makes output.

Signature

Lew

Esmond Pitt - 21 Jun 2007 12:03 GMT
> If method ( call it U ) in parent class is made private, then methods
> of child class can’t access U directly, but they still inherit this
> private method U.

Not in any useful sense, no, they don't inherit it at all.

> Is it similar situation if  parent method ( call it U1 ) is declared
> final  Meaning child methods can’t access U1 directly, but they still
> inherit it?

Adding 'final' to a private method has zero effect. It is already final.

> 2)
> Subclass can override parent’s class method by creating method with
> same name and same parameter list --> this is not true if parent
> method is declared private

Exactly so.

> So if compiler identifies a method by its name and its parameter list,
> then why do we get compile-time error if “hey()” in B is private
> ( compiler informing us that “hey()” can’t be overriden ):

because A.hey() was declared final so it explicitly can't be overridden.
What the actual point of that rule is is a mystery to me. Possible
compiler bug, ask the language lawyers. I no longer am one ...

>  , while compiler doesn't complain when “hey()” in class B is made
> public:

Possible compiler bug, see above.

> ? That would suggest that when it comes to overriding method, java
> doesn’t only distinguish between methods by their name and parameter
> list, but also by their access modifier.

It does indeed. It doesn't make much sense to me either, except that the
intent of whoever wrote private final void hey() in A was pretty clear
and the compiler is enforcing at least part of it.
Eric Sosman - 21 Jun 2007 13:35 GMT
>> 2)
>> Subclass can override parent’s class method by creating method with
[quoted text clipped - 23 lines]
> intent of whoever wrote private final void hey() in A was pretty clear
> and the compiler is enforcing at least part of it.

    I'm missing something here ...  What compiler message
do you get when a subclass has a private method with the
same name and signature as one in the superclass?  I get
no complaint at all for

    class Super {
       private void hey() {
           System.out.println("Super: Hey!");
       }
    }

    class Sub extends Super {
       private void hey() {
           System.out.println("Sub: Hey!");
       }
    }

In a sense this is not "overriding" because neither hey()
method is usable outside its class' own code.  But still:
what's all this talk of compiler errors?

Signature

Eric Sosman
esosman@acm-dot-org.invalid

Lew - 21 Jun 2007 14:22 GMT
>>> 2)
>>> Subclass can override parent’s class method by creating method with
>>> same name and same parameter list --> this is not true if parent
>>> method is declared private
>>
>> Exactly so.

Not at all so!

>>> So if compiler identifies a method by its name and its parameter list,
>>> then why do we get compile-time error if “hey()” in B is private
[quoted text clipped - 3 lines]
>> overridden. What the actual point of that rule is is a mystery to me.
>> Possible compiler bug, ask the language lawyers. I no longer am one ...

There is no such rule.

>>>  , while compiler doesn't complain when “hey()” in class B is made
>>> public:
>>
>> Possible compiler bug, see above.

Possible developer error?

Possible misleading report of the problem?

>>> ? That would suggest that when it comes to overriding method, java
>>> doesn’t only distinguish between methods by their name and parameter
[quoted text clipped - 3 lines]
>> the intent of whoever wrote private final void hey() in A was pretty
>> clear and the compiler is enforcing at least part of it.

Facts not in evidence.  Conclusion erroneous.

>     I'm missing something here ...  What compiler message
> do you get when a subclass has a private method with the
[quoted text clipped - 16 lines]
> method is usable outside its class' own code.  But still:
> what's all this talk of compiler errors?

Correct.  There is no such compiler error as that at which the OP hinted.

See my SSCCE upthread.

Signature

Lew

Lew - 21 Jun 2007 15:17 GMT
>>>> 2)
>>>> Subclass can override parent’s class method by creating method with
[quoted text clipped - 4 lines]
>
> Not at all so!

I am wrong.  I misread the quote the first time.  The above assertion "2)" is
accurate.

Signature

Lew

kaja_love160@yahoo.com - 25 Jun 2007 22:56 GMT
I sincerely apologise for the bug.
It's true that the code doesn't produce error ( I'm still not sure why
it did that since to my knowledge I haven't changed the code since and
now it runs fine )

But how can you claim that if parent class declared a method private
or final,then child class doesn't inherit the method? I know child
class can't access the method directly, but if what you've said was
true, then the following code wouldn't compile:

...
public static void main(String[] args) {
       B a = new B();
       a.aja();
   }
...

class A{

   public void aja(){
       hey();
   }

  final private void hey()
     {
       System.Out.Print("A.hey");
     }
}

class B extends A{...}

Again, I'm really sorry for all the troubles
Lew - 29 Jun 2007 06:06 GMT
> I sincerely apologise for the bug.
> It's true that the code doesn't produce error ( I'm still not sure why
[quoted text clipped - 26 lines]
>
> class B extends A{...}

You're right.  That code doesn't compile.

Signature

Lew

Roedy Green - 21 Jun 2007 12:34 GMT
>If method ( call it U ) in parent class is made private, then methods
>of child class can’t access U directly, but they still inherit this
>private method U.
>Is it similar situation if  parent method ( call it U1 ) is declared
>final ? Meaning child methods can’t access U1 directly, but they still
>inherit it?

final has to do with whether you can change a variable or override a
method or class.

It has nothing to do with visibility.

see http://mindprod.com/jgloss/final.html
http://mindprod.com/jgloss/scope.html
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Christian - 21 Jun 2007 13:29 GMT
Roedy Green schrieb:

>> If method ( call it U ) in parent class is made private, then methods
>> of child class can’t access U directly, but they still inherit this
[quoted text clipped - 14 lines]
> The Java Glossary
> http://mindprod.com

I would say not entirely..

for example:

for (final Object o: collection) {
   new Runnable() {
       public void run(){
         //do something with o
       }
   }
}

o gets visible to the anonymous class because of final

while allowing o  itself to be overriden for each object in the collection..

final seems to be a bit overloaded..

Christian
Lew - 21 Jun 2007 14:24 GMT
> Roedy Green schrieb:
>>
[quoted text clipped - 8 lines]
>>
>> It has nothing to do with visibility.

More correctly, it has nothing to do with accessibility.

>> see http://mindprod.com/jgloss/final.html
>> http://mindprod.com/jgloss/scope.html
[quoted text clipped - 20 lines]
>
> final seems to be a bit overloaded..

That is not a question of accessibility or visibility but of the inner class's
ability to rely on the variable's value.

Signature

Lew



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.