This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Looking at the implementations of many of the new concurrent collection types in 5.0 Tiger, In many cases a final lock variable used by a class is copied to a final variable on the stack in a locking method e.g.
Originally posted by l4strada: What is the benefit of this referencing the lock as a final on the stack over the heap?
When I started doing Java, this type of thing was common. I was told that local variables are faster to access than object fields, so I should copy fields to local variables in situations where the field would be accessed several times in the method.
I'm not sure how true that is now.
If the field is not "final" and the program is multi-threaded, another difference between the local variable version and the field version is that changes to the field in another thread will not affect a particular invocation of the method.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Your methods should not reference instance fields directly. You should use a getter for instance fields, such as: getLock().acquire(); This way your methods are not concerned with the actual object itself.
Consider if you upgrade the Lock object to an atomic reference. Then using lock.acquire() will not compile. You need lock.get(). Putting this into a getter relieves the using methods of knowing just how the object is stored.
Now whether the object lives on a heap or stack and the number of computer machine instructions it takes to access it may seem trivial. With the optimizing compilers we have today, the reference may even remain in a register or cache.