• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Marking an overridden method final

 
Michael Ernest
High Plains Drifter
Sheriff
Posts: 7292
Netbeans IDE VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Greg Brannon
Bartender
Posts: 563
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First paragraph of this link, though some may prefer a JLS reference.
 
Jelle Klap
Bartender
Posts: 1951
7
Eclipse IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Matthew Brown
Bartender
Posts: 4549
8
Java Netbeans IDE Scala
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 23
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 227
Eclipse IDE Java Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4549
8
Java Netbeans IDE Scala
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 6548
22
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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."
 
Greg Brannon
Bartender
Posts: 563
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 9494
50
Eclipse IDE Hibernate Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greg Brannon wrote:At least that's my interpretation....

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

Winston
 
Campbell Ritchie
Sheriff
Pie
Posts: 47293
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can we bring this thread back to its original question please.
 
Michael Ernest
High Plains Drifter
Sheriff
Posts: 7292
Netbeans IDE VI Editor
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 6548
22
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 47293
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 9494
50
Eclipse IDE Hibernate Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 47293
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 9494
50
Eclipse IDE Hibernate Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 47293
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 9494
50
Eclipse IDE Hibernate Ubuntu
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 47293
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic