No, the "final" keyword serves no purpose in that code AFAICT. I would go ahead and remove final from all catch exception arguments. (If there are cases where it's actually necessary, the compiler will tell you so.)
This is very different from declaring a field final, which is always a good thing when it can be arranged. --tim On Tue, Oct 14, 2008 at 3:26 PM, Jerome Louvel <[EMAIL PROTECTED]>wrote: > Hi Tim, > > I knew I should have left this one for you :-) > > I don't really remember why/how it got used there in the first place, but I > somehow have/had this belief that a final variable was consuming less > resources as it seems like a constant. > > Aren't we even saving a monitor or something? Maybe some CPU time due to > the fact that no synchronization is needed? :) > > If it doesn't bring anything, I think it will be good to clean them in the > code to prevent people getting worried. Let me know! > > Best regards, > Jérôme Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > ------------------------------ > *De :* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *De la part de* Tim > Peierls > *Envoyé :* mardi 14 octobre 2008 21:06 > *À :* [email protected] > *Cc :* Jerome Louvel > *Objet :* Re: XmlRepresentation.internalEval > > On Tue, Oct 14, 2008 at 2:41 PM, Jerome Louvel <[EMAIL PROTECTED] > > wrote: > >> For the 'final' keyword usage, it might save a bit of memory at most. No >> big gain here I suspect. > > > How would memory be saved? Are there really compilers that generate > different bytecode depending on the presence of the final keyword in this > case? > > try { > ... > } catch (/*final*/ Exception e) { > return null; > } > > The only reason I know to use final in the catch argument declaration is if > you need to refer to the exception from an inner class in the catch clause. > > --tim > > >
