File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes Marking an overridden method final Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Marking an overridden method final" Watch "Marking an overridden method final" New topic
Author

Marking an overridden method final

Michael Ernest
High Plains Drifter
Sheriff

Joined: Oct 25, 2000
Posts: 7292

Is it just me and my whelming self-identifying Irish charm or is this supposed to be forbidden?

Looks fine. I have two sources (of muddled credibility) saying you can't do it.

In related news, the next time you hear about a job writing test questions or writing a book for an exam, please knock some sense into me if I say yes.


Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Greg Brannon
Bartender

Joined: Oct 24, 2010
Posts: 563
First paragraph of this link, though some may prefer a JLS reference.


Always learning Java, currently using Eclipse on Fedora.
Linux user#: 501795
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1836
    
    7

Greg Brannon wrote:some may prefer a JLS reference.


Indeed

Paragraph 8.4.3.3 of the current JLS specifies that:

It is a compile-time error to attempt to override or hide a final method.


Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4490
    
    8

The thread title doesn't seem to quite match the code. You can't override a final method (that's what it's for). You can override a non-final method and mark it final, which is what the title seems to be about.
dirk dj jaeckel
Greenhorn

Joined: May 31, 2012
Posts: 23
Matthew Brown wrote:The thread title doesn't seem to quite match the code. You can't override a final method (that's what it's for). You can override a non-final method and mark it final, which is what the title seems to be about.

agreed
i struggled over the same
Aditya Jha
Ranch Hand

Joined: Aug 25, 2003
Posts: 227

Matthew Brown wrote:The thread title doesn't seem to quite match the code. You can't override a final method (that's what it's for). You can override a non-final method and mark it final, which is what the title seems to be about.

To be fair, the thread title says about "overridden method", and usually that is what we call the super class' method. The sub-class method which overrides the super class' (overridden) method is termed as "overriding method".

Though, I'm not sure what the original question was. Was it not the expected output of compilation?
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4490
    
    8

Aditya Jha wrote:
To be fair, the thread title says about "overridden method", and usually that is what we call the super class' method. The sub-class method which overrides the super class' (overridden) method is termed as "overriding method".

Fair enough. In that case, just ignore my post .
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5288
    
  10

Is the confusion about the "@Override" annotation or the final keyword? Seems like the former to me. I read it (@Override ... final) as saying "I'm overriding the behavior inherited from my parent but I don't want any of my children to be able to override the behavior they inherit from me."


Junilu - [How to Ask Questions] [How to Answer Questions]
Greg Brannon
Bartender

Joined: Oct 24, 2010
Posts: 563
I respect and usually admire the loyal contributors to this site for their near-anal accuracy, veracious pursuit of the truth, perfection, and preciseness in all things, and willingness (almost delight) in highlighting other's mistakes while somehow maintaining a good-natured civility that would be practically impossible to maintain under similar circumstances in the "polite" society most (?) of us inhabit during our daily lives in the concrete world. I say "usually admire," because even though I respect this site for those personality- and moderator-driven characteristics, sometimes the forums can only be taken in small doses precisely because of them.

While the OP's example may not have been perfect, and the thread title a little confusing, I interpreted the topic to be asking if it was acceptable to override a method that had been declared final. The OP had been given clear indications that that was the case by a compiler error, but had only "two sources (of muddled credibility)" to rely on. He was asking for confirmation. It's simple, just that.

The "@Override" annotation in the OP's example doesn't contribute to what I believe is the point of the topic, may add a tiny amount of confusion to understanding its point, but it more likely demonstrates the OP's confusion about the whole topic. In all, there's nothing technically wrong with it. The topic title suggests that at some point code existed that compiled fine. Then an overridden method in that code was declared final, resulting in a compiler error when next compiled. Maybe. Maybe it's just an imprecise title.

The OP's question is clearly about the error

At least that's my interpretation.

@Michael Ernest, you have the authoritative reference, JLS 8.4.3.3, that explains "A method can be declared final to prevent subclasses from overriding or hiding it." I believe that explains the error you've received and answers your question. Please explain further if not.

And if those you're writing the test questions or book for are like this site's faithful, I trust that you'll end up with a product to be proud of (if you don't get fired), but I wish you the patience of all the saints combined to survive their constructive criticism. Good luck!
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8419
    
  23

Greg Brannon wrote:At least that's my interpretation....

Now I'm confused. So you like this site, right?

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40052
    
  28
Can we bring this thread back to its original question please.
Michael Ernest
High Plains Drifter
Sheriff

Joined: Oct 25, 2000
Posts: 7292

I thought the title was pretty simple, but you have to slow down and read it a certain way, not just correctly.

If I override a method I have inherited, such as toString(), the doc I read says I shouldn't be able to mark it final, preventing others from implementing their own version. This idea came to me as I was summing up other ways in Java to effect the behavior of final that is more like protecting the code of the parent than preventing the child from doing its own thing. Anyway.

For about the same reason you cannot reduce the visiblity of an inherited method, it seemed reasonable to assert you couldn't finalize an inherited method. I dunno if I'm happy a person can finalize, say, equals(), but I guess that's open to programmer discretion.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5288
    
  10

Michael Ernest wrote:For about the same reason you cannot reduce the visiblity of an inherited method, it seemed reasonable to assert you couldn't finalize an inherited method. I dunno if I'm happy a person can finalize, say, equals(), but I guess that's open to programmer discretion.

I don't see the reason for not allowing visibility of an inherited method to be reduced as being applicable to finalizing an inherited method. If reducing the visibility of a method in subclasses were allowed, that could potentially break polymorphism / Liskov Substitution Principle. Finalizing an inherited method makes sense, for example, when you implement the Template Method pattern.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40052
    
  28
It doesn’t say anything in the Object class about toString, equals and hashCode about the overriding being final or not final. That is obviously a design decision on the part of whoever writes the classes. There is a recent discussion of final methods here.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8419
    
  23

Michael Ernest wrote:If I override a method I have inherited, such as toString(), the doc I read says I shouldn't be able to mark it final, preventing others from implementing their own version. This idea came to me as I was summing up other ways in Java to effect the behavior of final that is more like protecting the code of the parent than preventing the child from doing its own thing. Anyway.

Experts will correct me if I'm wrong, but I think it has to do with the way that Java "does it's stuff". I remember reading an article somewhere that said that 'all Java methods are virtual...unless they're final', and that's the way it makes sense to me.

I also remember that lots of optimization used to be based on whether methods are final - although I suspect that's old-hat now - but it makes sense to me as someone who doesn't know much more than the basics about how compilers do their stuff.

Personally, I love the way Java defines final. So much simpler than the C# interpretation, where overriding a final method is only a compiler warning and you have to "seal" things... 'Final' in Java means exactly what it says on the tin: "you cannot override this".

I'd be interested to know "the doc" you read, because it seems to have missed the point.

Winston
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40052
    
  28
Winston Gutkowski wrote: . . . I remember reading an article somewhere that said that 'all Java methods are virtual...unless they're final', . . .
I hope you found whoever wrote the article and shot him for mixing C++ terminology (virtual) and Java™ terminology. Another of my pet hates, (not nearly as bad as long lines and 2D arrays ) is people who go round writing about Java™ as if it were a superset of C++. It isn’t. It is a language in its own right, completely different from C++. And I think (my opinion, which I am sure people will disagree with) Gosling &c made a mistake in making it look like C++.

I have heard that quote before.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8419
    
  23

Campbell Ritchie wrote:I hope you found whoever wrote the article and shot him for mixing C++ terminology (virtual) and Java™ terminology.

Actually, correct me if I'm wrong, but isn't one of the Java bytecode commands that call methods that might be overridden (as opposed to 'direct' calls) something like 'callvirt'. I could well be wrong, because I don't do a lot of that stuff.

And I think (my opinion, which I am sure people will disagree with) Gosling &c made a mistake in making it look like C++.

There I'd have to disagree: I think it was one of the foundations of it's success. Certainly, it was the main thing that attracted me to it.

Winston
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40052
    
  28
Winston Gutkowski wrote: . . . isn't one of the Java bytecode commands . . . something like 'callvirt'.
Don’t know, but we can look in the JVM specification. I couldn’t find callvirt, but did find invokevirtual. That is an implementation detail which should be hidden from the public interface. It might be appropriate to use virtual there, if C++ code is used.

And I think (my opinion, which I am sure people will disagree with) Gosling &c made a mistake in making it look like C++.

There I'd have to disagree: I think it was one of the foundations of it's success. Certainly, it was the main thing that attracted me to it.

Winston
If you make a better mousetrap and it looks like an old‑style mousetrap . . .
The trouble is, that there are still people who think Java features which look like C++ features mean the same thing. Fortunately fewer than there used to be.

Fortunately, we can have different opinions, and the newbies can see that different opinions are valid.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8419
    
  23

Campbell Ritchie wrote:I couldn’t find callvirt, but did find invokevirtual.

That's the chap.

Fortunately, we can have different opinions, and the newbies can see that different opinions are valid.

Amen

Winston
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 40052
    
  28
I like that Jefferson quote. In fact, when I know my opinion is not a ”consensus” opinion, I usually say people will disagree. They can disagree as much as they like, but I know I am right.

I also know you are right with the conflicting opinion.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Marking an overridden method final