On Tue, Dec 9, 2008 at 1:20 PM, Paul Lindner <[EMAIL PROTECTED]> wrote:
> > On Dec 8, 2008, at 9:36 AM, Henning P. Schmiedehausen wrote: > > Paul Lindner <[EMAIL PROTECTED]> writes: >> >> The error string was generated for every single field when serializing >>> an object. So if you have the person object with say 10 fields you >>> generate 10 error message strings. That's a lot of Strings! >>> >> >> Yes, that is obvious. I was wondering about the final modifiers >> because this is how I tend to write code and a while back, a number of >> my patches were shot down because "this does not adhere to the rest of >> the shindig code". If we start changing this, that is better. >> >> [...] >> > > actually: > > http://cwiki.apache.org/SHINDIGxSITE/java-style.html > > > final > Use final whenever possible on all member variables. > > Reasoning: Avoids missing initialization. > > However, since this is a library I would not make anything but static inner > classes final. I think Henning was referring to final on method arguments, which is completely useless unless language semantics require them (say, inner classes). The current style guide only refers to member variables, where final is encouraged to promote type safety and ensuring explicit initialization is performed. I haven't seen a good argument for using final on method parameters, so the only remaining argument is consistency. If someone wants final on all method parameters, I say go for it, but first you have to update every method in every class in the entire code base to conform, and then get someone to review it for you. Good luck with that. > > > >> Well, then we'd have to duplicate code inside of each catch block. >>> >> >> It does give you the opportunity to customize the error message per >> catch block and it actually reduces the amount of unneccessarily >> created strings to 0. I would be interested to see this under YourKit >> profiler with 5k req/sec; I would guess that you would see another >> performance increase. >> >> > Actually each catch block calls the private method with the proper args. > We're good, but yes we could change this to accommodate a custom error > message. > > I'm pretty happy with the implementation as it stands. >>> >> >> That does not mean it is optimal. :-) >> > > > Indeed! > > > > Paul Lindner > [EMAIL PROTECTED] > > > >
