The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Java and final

I am looking for input about the merits of using final within Java for the sake of performance improvements.

We are having a discussion at my work about making all classes, methods, and variables (both local and class level) final where possible.  This is in the effort of performance optimization.

There is some debate centered around how much this really optimizes things, at the sake of readability, extensibility and maintainability.

I found this article that states that final methods (and implicitly classes) have no performance impact:

In addition, making all local variables final, especially when they are classes, seems to me it would only marginally improve performance.

Any input into any or all of this topic would be appreciated.

Seeker Send private email
Thursday, January 13, 2005
Have you tried using any profiling tools to see where the performance bottlenecks are in your application? When you know where the hotspots are, you can start optimizing.

Making everything final seems like you're taking a blind shot in the dark at optimization, without even trying to dig deeper into the application to find the real sources of your performance problems.
Benji Smith Send private email
Thursday, January 13, 2005
Making methods and classes final is a very different thing than making variables final. In addition to possbile minor performance gains, the former severely impacts the extensibility of your code.
Thursday, January 13, 2005
Research has shown that making a local variable final does not affect performance. The generated bytecode is almost identical. See
Janek Schwarz
Thursday, January 13, 2005
Read "Effective Java" if you haven't already. All sorts of cool stuff in there, amongst them why things might not be as final as you think they are. Not particularly performance oriented, though.
NetFreak Send private email
Thursday, January 13, 2005
Thanks for the link Janek.  That is the kind of stuff I am looking for.  Any other references are welcome.

I am not the one making these changes, but those who are applied final everywhere in the world they could.  I am mostly looking for hard facts to prove this is really a bad thing in most cases... I can live with class level final variables though... as they seem to be a good thing.

They are using a profiler, but in this case, they seem to be just "winging it".

One other obstacle in this debate I am meeting is that there appears to be conflicting sources about how useful final is.  Those who are making the changes claim several sources think final methods are a good thing.  And some handy-dandy tool they are using recommended it.

Any other references/comments would be welcome.

Seeker Send private email
Thursday, January 13, 2005
The final modifier is not about performance enhancement, but about stronger typing and cleaner, clearer code.

You should keep your code in good state at all times, with the correct typing in all scopes.
Thursday, January 13, 2005
Forgive me if i'm completely ignorant, but how would anyone even think that the 'final' keyword would affect the performance of methods?  Can someone explain the theory behind this?
Vince Send private email
Thursday, January 13, 2005
I think the theory goes like this.

Say you have a class Parent and a derived class Child inheriting Parent.  Parent has a doThis() method.  Now you declare:

Parent p = new Child();

If doThis() is not final, then Child can override it.  So whenever you call p.doThis() and p holds a class derived from Parent, the JVM has to check whether doThis() is overridden in the derived class, and if it is, it has to execute the subclass's doThis() instead of the Parent doThis().  But if doThis() in Parent is final, then the JVM doesn't ever need to check whether doThis() is overridden, so save some time.

But like most other areas of efficient code, it's worth asking how many people have experimented and how many just read somewhere that it's faster and took it on faith.
Kyralessa Send private email
Thursday, January 13, 2005
> The final modifier is not about performance enhancement,
> but about stronger typing and cleaner, clearer code.

+1, defineity
Carfield Yim Send private email
Thursday, January 13, 2005
Thanks for all the replies.  I also agree with the statement that the final modifier is not about performance enhancement, but about stronger typing and cleaner, clearer code.

In my opinion, it is far wiser to focus on the biggest performance areas of you code for optimization then to waste time shaving off a tiny percentage at the expense of the maintainability of the code.

Now all I have to do is convince the others :)

Seeker Send private email
Friday, January 14, 2005
Seeker, I've been fighting this battle at work for 3.5 years.  Not to put anybody down, but the "finalize everything" argument (at least in my group) comes from the part of the team that doesn't know how to optimize.  They use this as a crutch because they can't/won't optimize algorithms or their "design". 

Now, this isn't to say that the final keyword is bad, it has some handy uses.  Final static fields are nice for contstants , final classes are good if you write an immutable class for the sake of thread-safety.  However, putting the final keyword on everything is just overkill.  As others have stated, there's no perceptable gain to be had.  The product we develop has an very large load thrown at it (500+ requests/s) and the "finalize everything" crowd has still not been able to prove that we run any faster that way.
Joe Blandy
Friday, January 14, 2005

found another article:

Final has it's uses -- performance isn't one of them.

Janek Schwarz Send private email
Friday, January 14, 2005
Actually, from the article above: 'The revised memory model proposed by JSR 133 includes special provisions for final fields, provisions that are absent from the existing specification. Newer VMs already implement this specification, and treat final fields accordingly. Because final fields are assigned exactly once, aggressive optimizations in a multithreaded context become possible. Specifically, a field doesn't need to be ever reloaded, since its value is guaranteed never to change.'  That's not to say that anyone has implemented those optimizations yet tho.
r1ch Send private email
Saturday, January 15, 2005
note that while, in theory, a "final" field cannot be changed through normal methods (obj.finalField = 2) it can be changed quite easily using reflection.
Saturday, January 15, 2005
If you make a method final, you are allowing the compiler to turn any calls to that method into inline calls. When the compiler sees a final method call it can (at its discretion) skip the normal approach of inserting code to perform the method call mechanism (push arguments on the stack, hop over to the method code and execute it, hop back and clean off the stack arguments, and deal with the return value) and instead replace the method call with a copy of the actual code in the method body. This eliminates the overhead of the method call
Tuesday, January 25, 2005
This article in Java World goes so far as to say "Make everything final (unless there's a good reason not to)."

The author argues for this for security reasons.
Mike ewing Send private email
Monday, January 31, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz