Back in the dim and distant past I remember final being used to give the JIT an optimization hint that whatever's described as final can be inlined as it won't change (note JIT not compiler). It's not a big saving, but in tight loops and heavily called code it can all add up.
I found http://www.javaperformancetuning.com/tips/final.shtml which expands on it a bit. Al. -- * Written an Android App? - List it at http://andappstore.com/ * ====== Funky Android Limited is registered in England & Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK. The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries. -----Original Message----- From: Wes Wannemacher [mailto:w...@wantii.com] Sent: 03 June 2009 16:02 To: Struts Developers List Subject: use of private final vs. protected I am looking at subclassing JakartaMultiPartRequest and almost all of the members are 'private final', but they are Lists and Maps, so I am curious what the justification is... I want to subclass and get at the data, obviously I'd have to change the declarations to protected, but is final necessary? From what I can see, the only thing it guarantees is that with each instance of JakartaMultiPartRequest, the Lists or Maps will point to new instances. I guess what I'm wondering is if there is an intention to follow a coding standard or something that I'm missing because I don't see much point for these members to be private or final (especially since it makes it pretty much impossible for me to subclass it). -Wes -- Wes Wannemacher Author - Struts 2 In Practice Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more http://www.manning.com/wannemacher --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
