Go for it. Just work out your changes, create a patch and attach it to the issue you opened. In terms of passivity, one of the key implementation aspects to consider is that serialization works correctly for both classes afterwards.
-Nathan > -----Original Message----- > From: Alexey Varlamov [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 10, 2006 2:43 AM > To: [email protected] > Subject: [classlib] StringBuilder vs StringBuffer > > Folks, > I've noticed that available implementation of j.l.StringBuilder > performs quite slowly, so j.l.StringBuffer outperforms it several > times despite of all synchronization. I filed corresponding JIRA > tracker, HARMONY-589. > > Yet there is one issue which I'd like to raise here - code duplication > between these classes. AFAIU they are almost identical, except > synchronization and return types, -therefore will perfectly fit to a > common superclass. > BTW, RI goes exactly this way - one can look at official specification > of corresponding serialized forms to ascertain that, so there will be > no compartibility issues. > > If noone objects, I volunteer to do this refactoring. Guess it does > not require any golden tickets :) Should I assign the JIRA issue to > myself? Or any other steps needed? > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
