>>>>> "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
