Am Die, 29 Aug 2000 schrieb Dalibor Topic:
Is it not fair to assume that converting n bytes will result in less than
or equal to n characters?
For most of encodings that I've seen, it is a safe assumption.
Unfortunately, I haven't seen 'em all :)
I'm suspicious that it's
possible
Hi Godmar,
Am Die, 29 Aug 2000 schrieb Godmar Back:
I was looking at this function in String.java:
private static StringBuffer decodeBytes(byte[] bytes, int offset,
int len, ByteToCharConverter encoding) {
StringBuffer sbuf = new StringBuffer(len);
Godmar Back wrote:
[...] Every call results in a new
converter object being newinstanced, just to convert a bunch of bytes.
(The new converter was one of the changes done to make the
charset conversion thread-safe.)
[...]
And why exactly default converter could not be cached and same
Hi Godmar,
sorry for the delay, but I was on holidays last week, and away from my
mail.
Am Sam, 19 Aug 2000 schrieben Sie:
From what I understand, and someone correct me if I'm wrong,
there shouldn't be any reason not to include the change you suggest -
if someone implements it, of course.
Godmar Back wrote:
[...] Every call results in a new
converter object being newinstanced, just to convert a bunch of bytes.
(The new converter was one of the changes done to make the
charset conversion thread-safe.)
[...]
And why exactly default converter could not be cached
Godmar Back wrote:
It is not stateless; it keeps track of not converted characters/bytes
if there are any left. See the carry/flush methods.
The converter only converts 512 bytes at a time (see String.decodeBytes).
Now just why the converter does that, I don't know. It's not
Am Mon, 28 Aug 2000 schrieb Artur Biesiadowski:
And why exactly default converter could not be cached and same instance
used for all conversions ? I think it is stateless class, so it should
be safe to enter same object method from various threads with all state
on stack.
It depends on the
From what I understand, and someone correct me if I'm wrong,
there shouldn't be any reason not to include the change you suggest -
if someone implements it, of course.
If I understand your proposal right, you'd use an array for
the first 256 values and a hashtable or something like that
for
