Ok. I'll commit this one. >>>>>>>>>>>> [EMAIL PROTECTED] wrote (2006-01-20 14:15:34): > >>>>> "BP" == Bryan Pendleton <[EMAIL PROTECTED]> writes: > > BP> Dyre Tjeldvoll (JIRA) wrote: > >>> A solution is to keep the commonly used SQLStates as byte[] constants > that can be inserted into the message with writeBytes(). > > BP> I think that the solution shows great promise, but the patch > BP> that you provided seems too "open coded" for me. > > BP> It seems to me that the recently-added DRDAString class could > BP> be used as the encapsulation vehicle for this String/byte[] > BP> caching stuff, so that the bulk of the DRDA code didn't have > BP> to be so involved in the details of when to use the string and > BP> when to use the byte array. > > BP> So instead of seeing a bunch of changes like: > > BP> - writer.writeString(server.prdId); > BP> + // Write the byte[] constant rather than the string, for > efficiency > BP> + writer.writeBytes(server.prdIdBytes_); > > BP> which seems to mean that we'd have to maintain constant vigilance > BP> into the future to make sure that we know when to use the String > BP> versus when to use the byte[], it seems like we should turn an > BP> object like server.prdId into a DRDAString, and then let DDMWriter > BP> and DRDAString work out the details themselves about whether to use > BP> the String or the byte[]. > > BP> Does this make any sense? Am I barking up the wrong tree? > > I see your point, and was thinking along these lines for a while. I > was thinking about making a String replacement that kept a String and > a byte[] internally and did the conversion on demand and cached the > result. > > But then I decided that such a solution would provide much more > functionality than what was needed. Keep in that these values are in > fact constants, and they are not used for anything other than filling > messages, and so, unlike DRDAStrings, they don't need a String > interface. The DRDAStrings need to work as Strings AND be compared > efficiently to a segment of a byte array. > > I see that such a WrapperString clould be useful for future work, but > it also has its problems. Using a replacement for String is tedious > since you cannot extend the String class. You have to create a wrapper > (like DRDAString) and change the signature of every method that > takes a String argument to take the WrapperString as argument. And > frequently you'll still need to provide an overload for String as > well. > > Also, if you want to be able to use your String replacement generally > you have to come up with a place to put it. And as the "sharing common > code" discussions have shown, that is not always as easy as it > sounds... > > To conclude, I will not implment and use such a data type for this > patch (it is not my itch), but others should feel free to do so. > > (For the record, I would not have replaced Strings with byte[], if was > not for the fact that the profiler told me that this was a hotspot) > > > -- > dt > > However, experience shows that for many people and many applications a > dose of paranoia is reasonable - Bjarne Stroustrup >
-- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
pgpo9C418bslr.pgp
Description: PGP signature
