On Mon, 16 Feb 2004, Ted Husted wrote: > 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.
+1 I like the "bridge" packages idea, because it makes it clear where our potential dependencies are, as well as how extensive they are. -- Martin Cooper > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
