On Sat, 2006-10-14 at 08:07 -0400, James Carman wrote:
> Tomcat had this same issue a while back. It was trying to use a single
> SimpleDateFormat object to parse/format date-valued HTTP headers. I
> submitted the patch for it and I think we decided to just instantiate as
> needed. Local variables are garbage collected much more reliably from
> what I understand. And, as Simon pointed out, the probable disk i/o would
> be the big bottleneck, not the object instantiation.
Ok, so next issue: this member is declared protected:
static protected DateFormat dateFormatter = null;
(and initialised via a static block on the class).
This means that removing it is a binary-incompatible change; any
subclasses will be broken. Sigh. Once again we learn the lesson that
protected members should be avoided just like public ones, as the
binary-compatibility issue they cause are exactly the same.
I'd be willing to bet money that no-one in the world has ever subclassed
SimpleLog, but the issue is there. And of course binary compatibility is
a very big issue for such a core lib as logging.
Options:
(1) leave this member here, but don't use it.
(2) remove it, and release as 1.1.1
(3) remove it, and increment logging version to 1.2
This option does mean that code will continue to run, but if anyone
*had* subclassed SimpleLog then they would get output in the default
format, not their customised format. As they presumably had a good
reason for customising the output, their app may misbehave due to a
bugfix-level change.
Option 2 could potentially cause an existing application to throw an
exception when the SimpleLog subclass tries to access member
dateFormatter.
Option 3 is the theoretically correct one, but is rather overkill for
such a small change.
I'm tempted to choose (1), though none of the options are terribly
appealing.
Comments anyone?
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
