Comments on: A final bit of advice

By: Jeff Grigg

Jeff Grigg — Fri, 19 Mar 2010 12:33:06 +0000

Yes, as the article the previous poster referenced (http://www.ibm.com/developerworks/java/library/j-jtp1029.html) says, “final” is useless as a performance improvement technique: The compiler can’t use it, and the JIT runtime optimizer doesn’t need it. The runtime JIT will routinely inline non-final methods that don’t happen to be overridden by currently loaded sublcasses. And it’s smart enough to undo the inlining if a newly loaded subclass does override the method. So final is useless as a performance optimization technique.

By: Anonymous

Anonymous — Sat, 29 Nov 2008 01:44:48 +0000

FYI, a complete discussion on the topic: http://www.ibm.com/developerworks/java/library/j-jtp1029.html

By: Buddy Casino

Buddy Casino — Thu, 27 Nov 2008 09:23:30 +0000

I like final method parameters in larger methods, especially for primitive types. That way, I don’t have to scan the whole method body for parameter modification and can just safely assume that I get what I think I get.

I agree with the rest, though.

By: Paul Holser

Paul Holser — Thu, 27 Nov 2008 02:24:51 +0000

Right on.

By: Alex

Alex — Wed, 26 Nov 2008 21:24:20 +0000

@Casper: I didn’t comment as any performance tip like this has a half life of about 6 months. I’d love to see a program that could actually detect a difference in performance between a final and non-final method. :) Worrying about that is a waste of time…

I agree that it would be good to have more official options regardng “effectively immutable” objects. This comes up occasionally on the Java Memory Model and concurrency mailing lists. See here for example: Documenting Effective Immutability. It does seem like something that JSR 305 could define and that tools like FindBugs could verify.