Costin Manolache wrote:
Well, long time ago CharChunk and ByteChunk were supposed to be just an implementation detail of MessageBytes - which was supposed to hide the detail of chars and bytes and avoid the strings. But they were supposed to work together, and stay kind of consistent.
I am not against it, as other parts of the code assume the default HTTP encoding when dealing with bytes. User code can use toChars or toString to force character conversion whenever needed, so it looks reasonably safe.
Sorry :-) I guess it had something to do with jdk compat ? Well, too lazy to search - but I doubt any reason would be valid today, most VMs have this.
No idea, you said no because it would break API compatibility, or something like it. So I thought this was a misunderstanding about what the change was about.
Rémy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
