private final method??

[Raghu Arikeri]

Hi all,
what is the significance of a private final method? Do we ever use it?

[Peter Chase]

It is legal, but pointless, to declare a private method final.

[Rahul Bhattacharjee]

The code will compile but what is the use?
If the method is private , then anyways that will not be visible for overriding , so final is redundant.

[Burkhard Hassel]

Hi ranchers,

I find it worse than only useless, for this reason:

class Main {
public static void main(String[] args) {
A poly = new B();
poly.foo(); // <-- nocompile
}
}
class A {
private final void foo() {
System.out.println("foo");
}
}
class B extends A{
void foo() {
System.out.println("foo foo");
}
}

Yours,
Bu.

[Paul Sturrock]

Hmm. Here you declare an object with the type A. A does not have a visible foo() method, regardless of whether it is final or not. Perhaps I'm missing something, but how does making the private mthod final matter here?

[Burkhard Hassel]

No, you don't miss anything, I justed fooled myself.

Yours,
Bu.

[Svend Rost]

Hi,

No, private final methods arn't used that often.

In some cases it can be usefull to declare a method as 'private final'.
Either as documentation or in the case where the access level of the
method might be changed.


/Svend Rost

edit: Removed an erroneous paragraph.
[ November 09, 2006: Message edited by: Svend Rost ]

[Peter Chase]

Originally posted by Svend Rost:
In fact, all private methods are final

No, "final" has no meaning for private methods. The "final" keyword is about controlling overriding by subclass, but private methods cannot be overridden (or even seen) by the subclass. Like I said at the top, it is legal, but pointless, to declare a private method final.

[Svend Rost]

Originally posted by Peter Chase:

The "final" keyword is about controlling overriding by subclass, but private methods cannot be overridden (or even seen) by the subclass.

True, however:

http://www.javaworld.com/javaworld/javaqa/2000-09/02-qa-0915-private.html
yes, all compilers will treat private methods as final. The compiler will not allow any private method to be overridden. Likewise, all compilers will prevent subclasses from overriding final methods.

Originally posted by Peter Chase:

Like I said at the top, it is legal, but pointless, to declare a private method final.

Unless you wish to use it for documentational purpose, or state clearly
that is should be final (in case the access level gets changed). Ofcause,
you should prefeerably document this in another way. My point was just
to give an example of how private final could be used.

[Ernest Friedman-Hill]

http://www.javaworld.com/javaworld/javaqa/2000-09/02-qa-0915-private.html
yes, all compilers will treat private methods as final. The compiler will not allow any private method to be overridden. Likewise, all compilers will prevent subclasses from overriding final methods.

Don't believe everything you read; this is quite false, as is easy to demonstrate:

class Foo { private void x() {}}
class Bar extends Foo { void x() {}}

This code compiles just fine.

[Jim Yingst]

I must respectfully disagree with the delegate from Maryland. That isn't overriding, as there is no relationship between the two methods other than coincidentally having the same name. The two methods may have completely different return types and throws clauses. There is no circumstance under which byte code which (at compile time) calls Foo.x() might instead invoke Bar.x() based on the run-time lookup of the actual class of the invoking instance. "Real" overrides (as the term is used in Java) have restrictions on the return type and throws clause, and participate in dynamic method lookup. Which is why the JLS definition of override requires that the method to be overridden must be public, protected, or package access. An inaccessible method can't be overridden.

[Burkhard Hassel]

Jim Yingst posted November 09, 2006 10:39 AM

I must respectfully disagree with the delegate from Maryland.

Wasn't it be "the gentleman from Maryland?"

Ernest Friedman-Hill posted November 09, 2006 05:52 AM

class Foo { private void x() {}}
class Bar extends Foo { void x() {}}

This code compiles just fine.

Nobody claimed this to be overriding.
The same with final instead of private won't compile. That's all. So the critics about that Javaworld article is at least understandable.



Yours,
Bu.

[Jim Yingst]

[Burkhard]: Wasn't it be "the gentleman from Maryland?"

Yes, that's the phrasing I was looking for, thanks.

[Burkhard]: Nobody claimed this to be overriding.

Well, this code was posted as a refutation of the following:

yes, all compilers will treat private methods as final. The compiler will not allow any private method to be overridden. Likewise, all compilers will prevent subclasses from overriding final methods.

Of those three sentences, I say the first is false, but the latter two are true. I would think that if EFH were only disagreeing with the first sentence, there would be no need to quote the second and third, and the point would have been better served by also posting some code that used final, for comparison. Since he didn't do that, I think it's much more likely that EFH was addressing the second and third sentences with his code - and in that case, I disagree, for the reasons I gave.

Incidentally there are some possible loopholes in the original question if we also consider nested classes. Which is probably outside the scope of the original question; I just mention it now to be clear that I wasn't considering nested classes in my previous comments.

[Burkhard Hassel]

Jim Yingst posted November 09, 2006 03:26 PM

[Burkhard]: Wasn't it be "the gentleman from Maryland?"

Yes, that's the phrasing I was looking for, thanks.

You're welcome. Oh, I just remembered looking at a TV broadcast from the House of Representatives first, where they constantly addressed each other as "the gentleman from California" etc. without using their names. It was so funny for me!

and (Jim Yingst):

I would think that if EFH were only disagreeing with the first sentence, there would be no need to quote the second and third, and the point would have been better served by also posting some code that used final, for comparison.

OK. But "likewise,all compilers will prevent subclasses from overriding final methods." is a bit unclear. For me "further" or something like that would sound a little better for me.



Yours,
Bu.

[Ernest Friedman-Hill]

I certainly agree with Jim about the JLS interpretation of the term "overriding"; but I don't believe that this is what the author had in mind when they wrote "all compilers will prevent subclasses from overriding final methods." To me, that suggests that they're saying a compile-time error will ensue. There is nothing in the bytecode for a class that says "this method overrides this other method over here. This is resolved by the JVM when classes are loaded, not by the compiler. Therefore, even if we take what Jim is saying into consideration, this statement is still false -- the compiler has nothing to do with it.

And although Burkhard is right about the customary form of address, I must hasten to point out that I am no gentleman

[Jim Yingst]

Yeah, I wasn't going to say anything about the real reason I didn't use that word.

I suspect we're just going around in circles here chasing down the best way to describe what's wrong with the quoted statements from the JavaWorld article, since we both agree there's something wrong there, but seem to have different interpretations of what the author was thinking from one sentence to the next. And since he's not here for grilling, there's probably little point to that.

[EFH]: To me, that suggests that they're saying a compile-time error will ensue.

Yes, "does not allow" is misleading in this case as there's no error. On the other hand your refutation made it sound to me like you could override a private method, which also seemed misleading. Then too in my first reply I probably made it sound like I have no disagreement with the JavaWorld article, and that's misleading too. This is like a rug with a wrinkle in it - when we try to smooth out the one wrinkle, we accidentally create another elsewhere. Might as well stop now, given that no one really uses this particular rug anyway.