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. > 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)? RG
