Stanimir Stamenkov wrote:
/Stephen Kestle/:
Of course it is because Characters should not need to specify
encoding, but xml IS NOT a character stream - it's an encoded
character stream [...]
Don't want to spam the list but: XML _is_ a character stream. The byte
encoded representation is for transport means as most data in the
computer world is stored as sequences of bytes. Your sentence seems to
me like: "DOM is not an object, it is an 'encoded' XML stream".
Ok - I sort of agree - the critical point I'm trying to make is that
it's encoded (when it's valid). In Java, chars and Strings [IMO] infer
decoded (ie. screen printable) characters.
Please stop the madness - just deprecate it and write a nice javadoc
explaining why. You'll probably end up saving 1000s of developer
hours on that change alone.
You know, I've thought of that many times too, but what if I need to
write to a character buffer and not a byte one? I think it is just
problem of the less experienced developers which doesn't realize what
actually happens when encoding text to a byte stream and in particular
serializing XML.
Well you can always wrap it! Why make something hard to use for people
who are learning in favour of what should be exceptional (and advanced!)
usage. But then, if you had to make a WriterOutputStream, you'd have to
wonder why it hasn't been done before (as far as I can see). If you're
serializing an object, you're about to make it external to the system -
and there's no good reason to use a Character stream for this (which
will export in the default encoding, unless you make it a stream of some
sort...).
Most developers will expect it to return encoded data that is valid,
never realising that their code is fragile and will break when someone
puts some accidental value on a web screen. I can't see how this isn't
broken - the serializer slaps a header on it which claims it's encoded -
but it isn't!
When Date was found to be non-transportable, Sun deprecated a whole lot
of stuff. Please follow common java conventions (both Writer vs Stream,
and deprecation) and do the same.
In Summary: you are technically correct, but think about the social
[developer] impact of maintaining an "I'm right" stance. End developers
surely can't realistically complain about having to make a non-standard
WriterOutputStream for a non-standard operation. Even the advanced
users who would use this would have seen noob code that had to be
cleaned up (as I have had to do)
But I am interested to know if there is a use case for this. Although I
highly suspect that most use cases would be broken.
Thanks
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
