Robert Greig wrote:
On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote:
I do mean lazily decode, however not like the AMQShortString
implementation does. It currently just casts from byte to char. This
only works if the string consists entirely of non extended ASCII. I was
thinking more along the lines of internally converting to a char[] using
the proper charset decoder the first time the charAt(idx) method from
the CharSequence interface is used.
OK but using the charset decoder is 5x slower than casting from byte to char.
It is also approximately 5x more correct. ;)
Seriously though, if we actually need to operate on chars then there is
no point in casting. Short of modifying the protocol to redefine
shortstr as ASCII only, that will not result in the character that the
client intended to send.
This would provide correct unicode
character conversion for clients, and cause no overhead to the broker
since the broker just needs to do hash lookups based on the shortstr
values, and hashCode() and equals() can be implemented without doing
full character conversion.
Maybe I'm being particularly dim today but I don't follow. Let's say
the broker gets a Basic.Publish, it has to decode the routing key,
right? What hash lookups can it do without converting that buffer to a
String (irrespective of whether it does so using a slow charset
decoder or a quick cast)?
The hashCode() and equals() method in AMQShortString are currently
computed based solely on the raw shortstr bytes. They will function
correctly when hashing against and comparing to other AMQShortString
instances.
--Rafael
