Yes, there lies the rub: If we were to submit a patch to commons-lang today, we could not roll a (potentially) GA-quality release tomorrow. At least not without also rolling a release of commons-lang and waiting for it to "go platinum" first.
My suggestion would be that we start using "bridge packages" to isolate classes that we intend to submit to the Commons. Once the code in our bridge package proves it worth, we can then offer to the corresponding Commons package. If our code is accepted and the updated Commons package hits a General Availability release, we can then move our dependency from the bridge package to the Commons package. So, if we do determine that a change to the string handling is a difference that makes a difference, we could create a package for methods specifically earmarked for lang, such as o.a.s.commons.lang. Once we release our code, and find that it works well in the field, then we can submit a patch to c-l and roll a release there. Once the c-l is GA with our addition, then we can move the dependency in our on code from o.a.s.commons.lang to o.a.c.lang. This would similar to the approach we are trying with commons-resources: Release the code, copy the code, release the code again, *then* move the dependency. -Ted. On Mon, 16 Feb 2004 12:41:05 +0800, Andrew Hill wrote: > <snip> > Maybe now thats been done there should be a policy of > only developing against "release" versions of commons code. > </snip> > > > +1 > This seems pretty sensible to me. Id suggest the committers > seriously consider this idea. > > > -----Original Message----- > From: Niall Pemberton [mailto:[EMAIL PROTECTED] > Sent: Monday, 16 February 2004 08:58 > To: Struts Developers List > Subject: Re: string concatenation > > > I agree. > > > I seem to recall there were problems releasing Struts 1.1 because > of a hold up getting a commons component released that struts was > depending on. That was understandable as various bits of struts > were being moved over to commons at the time. Maybe now thats been > done there should be a policy of only developing against "release" > versions of commons code. That way commons doesn't become something > Struts has to wait on and its being developed against stable fully > tested commons components. > > Niall > > > ----- Original Message ----- > From: "Hablutzel, Robert" <[EMAIL PROTECTED]> > To: "Struts Developers List" <[EMAIL PROTECTED]> > "Struts Developers List" <[EMAIL PROTECTED]> Sent: > Monday, February 16, 2004 12:32 AM Subject: RE: string concatenation > > >> So I'm a bit of a lurker here, but I wanted to put in my $.02. >> >> >> I'd rather see a dependency on efficiently implemented code in a >> single >> > place than either replicating the code or using a less efficient > algorithm. Replication just means that bugs in the code aren't > fixed in all places, adds confusion to users as to which version to > leverage, and makes it harder to introduce possible future code > improvements. Trading memory for speed can be a meaningless > tradeoff in high-volume applications where the number of GCs > visibly impacts overall system performance. > >> >> My preference would be for leveraging code that is in a logical >> place (ala >> > commons-lang) and documenting the dependencies. > >> >> hab >> >> >> -----Original Message----- >> From: Martin Cooper [mailto:[EMAIL PROTECTED] >> Sent: Sun 2/15/2004 4:21 PM >> To: Struts Developers List >> Cc: >> Subject: RE: string concatenation >> >> >>> -----Original Message----- >>> From: David Graham [mailto:[EMAIL PROTECTED] >>> Sent: Sunday, February 15, 2004 1:01 PM >>> To: Struts Developers List >>> Subject: RE: string concatenation >>> >>> >>> Struts has many dependencies already and I'd like to avoid >>> adding one >>> > with >>> lang. Why not just size a large StringBuffer and trade memory >>> for >>> > speed? > >> >> We already have a dependency on Lang, albeit indirectly, so why >> not take advantage of it? >> >> Frankly, I disagree with the push I see from some folks >> (including Craig >> > on >> commons-dev recently) to reduce dependencies between components by >> duplicating functionality. The whole point of Commons is to avoid >> duplication, so why are people pushing back against using the >> successful components that we helped create here in Struts? >> >> -- >> Martin Cooper >> >>> >>> David >>> >>> >>> --- Martin Cooper <[EMAIL PROTECTED]> wrote: >>>> Rather than add a new string utility class to Struts, which >>>> isn't >>>> > really >>>> where it should belong, I think we'd be better off just using >>>> this: >>>> >>>> >>> http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang /St >>> ringUti >>> >>>> ls.html#join(java.lang.Object[]) >>>> >>>> >>>> Alternatively, you could suggest (on the commons-dev list) >>>> adding a variation of your StringHolder class, based on the >>>> join() method >>>> > above, >>>> to >>>> Commons Lang. >>>> >>>> >>>> -- >>>> Martin Cooper >>>> >>>> >>>>> -----Original Message----- >>>>> From: nishant kumar [mailto:[EMAIL PROTECTED] >>>>> Sent: Saturday, February 14, 2004 5:46 PM >>>>> To: [EMAIL PROTECTED] >>>>> Subject: string concatenation >>>>> >>>>> >>>>> hi, >>>>> I have a performance tuning suggestion which i think will >>>>> greatly impact the performance of struts html tags. String >>>>> concatenation using StringBuffer is definitely much better >>>>> than >>>>> using the plus operator but there are scenarios where there >>>>> are much better ways than using StringBuffers. Actually >>>>> struts html tags fall >>>>> >>>> in >>>>> those scenarios. >>>>> So let me give you an example. this is the code from >>>>> renderFormStartElement method of FormTag. >>>>> >>>>> >>>>> StringBuffer results = new StringBuffer(); >>>>> results.append("<form"); >>>>> results.append(" name=\""); >>>>> results.append(beanName); >>>>> results.append("\""); >>>>> results.append(" method=\""); >>>>> results.append(method == null ? "post" : method); >>>>> results.append("\" action=\""); >>>>> .... >>>>> str = results.toString(); >>>>> >>>>> >>>>> pageContext.getOut().write(str); >>>>> >>>>> >>>>> Now lets list the issues with this. >>>>> 1. first presizing this buffer is quite difficult (avoided >>>>> in this case). here the buffer starts with size 16 and >>>>> doubles each time the size is exceeded. This causes >>>>> unnecessary creation of new char >>>>> > arrays >>>>> and redundant copy of data whenever resizing happens. >>>>> 2. whenever append is called data is copied from the passed >>>>> string >>>>> > to >>>>> the end of stringbuffer. >>>>> 3. finally the whole concatenated data is again copied into >>>>> another string. >>>>> 4. and then in the end this string is written to a writer, >>>>> another >>>>> >>>> copy, >>>>> which is the only copy required. >>>>> >>>>> >>>>> so even if you had presized the stringbuffer correctly, you >>>>> have >>>>> >>>> copied >>>>> the same data thrice instead of just once. And you also >>>>> create two >>>>> > NOT >>>>> needed objects. >>>>> >>>>> >>>>> so here is the solution i propose. have a class holding an >>>>> array >>>>> > of >>>>> Strings and keep appending strings to this array and >>>>> finally print >>>>> >>>> this >>>>> array to the writer. something like this. >>>>> >>>>> >>>>> private String[] data = new String[256]; >>>>> private int size = 0; >>>>> >>>>> >>>>> public StringHolder append(String str){ >>>>> ensureCapacity(this.size + 1); >>>>> this.data[this.size++] = str; >>>>> return this; >>>>> } >>>>> >>>>> >>>>> public void writeTo(Writer out) throws IOException{ >>>>> for (int i = 0; i < this.size; i++){ >>>>> if (this.data[i] != null){ >>>>> out.write(this.data[i]); >>>>> } >>>>> } >>>>> } >>>>> >>>>> >>>>> this way only the last copy takes place and you also avoid >>>>> creating >>>>> > so >>>>> much garbage. >>>>> >>>>> >>>>> i have attached StringHolder class which does the above >>>>> task and >>>>> > also >>>>> the FormTag after making necessary modification to fit in >>>>> this >>>>> > class. >>>>>> From the code of FormTag you can see that you need to >>>>>> make quite >>>>>> > few >>>>> changes to get great benefit. >>>>> >>>>> >>>>> i have also attached a better implementation of >>>>> ResponseUtils.filter(String) method. the logic is on the >>>>> same lines >>>>> > as >>>>> above. >>>>> >>>>> >>>>> thanks, >>>>> nishant >>>>> >>>>> >>>>> -- >>>>> nishant kumar <[EMAIL PROTECTED]> >>>> >>>> >>>> -------------------------------------------------------------- >>>> ------- To unsubscribe, e-mail: struts-dev- >>>> [EMAIL PROTECTED] For additional commands, e- >>>> mail: [EMAIL PROTECTED] >>> >>> >>> __________________________________ >>> Do you Yahoo!? >>> Yahoo! Finance: Get your refund fast by filing online. >>> http://taxes.yahoo.com/filing.html >>> >>> >>> ---------------------------------------------------------------- >>> ----- To unsubscribe, e-mail: struts-dev- >>> [EMAIL PROTECTED] For additional commands, e-mail: >>> [EMAIL PROTECTED] >> >> >> ------------------------------------------------------------------ >> --- To unsubscribe, e-mail: struts-dev- >> [EMAIL PROTECTED] >> For additional commands, e-mail: struts-dev- >> [EMAIL PROTECTED] > > > -------------------------------------------------------------------- > - To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -------------------------------------------------------------------- > - To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
