At 01:45 PM 11/15/2004, Philippe Verdy wrote:
Deprecated does not mean that it is not used. This interface remains
accessible when working with internal class file format. I don't
understand however why the storage format of the string constants pool was
not changed when the class format was
on this Java URL?)
Doug Ewell scripsit:
As soon as you can think of one, let me know. I can think of plenty of
*binary* protocols that require zero bytes, but no *text* protocols.
Most languages other than C define a string as a sequence of characters
rather than a sequence of non-null characters
Isn't it already deprecated? The URL that started this thread
http://java.sun.com/j2se/1.5.0/docs/api/java/io/DataInput.html
is marked as part of the Deprecated API
- Chris
Norbert Lindenberg wrote:
Theodore,
Thank you for your feedback. Adding a warning to the description in
DataInput sounds
From: Christopher Fynn [EMAIL PROTECTED]
Isn't it already deprecated? The URL that started this thread
http://java.sun.com/j2se/1.5.0/docs/api/java/io/DataInput.html
is marked as part of the Deprecated API
Deprecated does not mean that it is not used. This interface remains
accessible when
Asmus Freytag asmusf at ix dot netcom dot com wrote:
The way UTC formally 'acknowledges' something like that may involve
the issuance of a specification for it. That was done for CESU-8, and
incidentally also for UTF-EBCDIC.
Throughout all of this, I had completely missed the fact that the
At 10:21 AM 11/14/2004, Doug Ewell wrote:
Throughout all of this, I had completely missed the fact that the Tech
Note for CESU-8 had been upgraded to a Tech Report, two and a half years
ago, in fact. Perhaps I was in denial. Anyway, that ... invalidates many
of my comments...
Noted.
CESU-8 is
On 14/11/2004 07:36, Doug Ewell wrote:
...
An unusual type of compatible that makes a special allowance for
strings with embedded nulls, impossible by definition in C.
If the Java architects had wanted a variable-length array of arbitrary
byte data, they should have created such a type in the
Philippe Verdy writes:
Nulls are legal Unicode characters, also for use in plain text and since
ever in ASCII, and all ISO 8-bit charset standards. Why do you want that a
legal Unicode string containing NULL (U+) *characters* become illegal
when converted to C strings?
Why do you
Philippe Verdy verdy underscore p at wanadoo dot fr wrote:
Nulls are legal Unicode characters, also for use in plain text and
since ever in ASCII, and all ISO 8-bit charset standards. Why do you
want that a legal Unicode string containing NULL (U+) *characters*
become illegal when
Asmus Freytag asmusf at ix dot netcom dot com wrote:
There are some UTF-8/UTF-16 interoperability aspects that are
addressed by CESU-8. These concerns are real, and affect multi-
component architectures that must interchange data across component
boundaries. Therefore a standard specification
Doug Ewell scripsit:
As soon as you can think of one, let me know. I can think of plenty of
*binary* protocols that require zero bytes, but no *text* protocols.
Most languages other than C define a string as a sequence of characters
rather than a sequence of non-null characters. The
At 10:01 PM 11/14/2004, Doug Ewell wrote:
Asmus Freytag asmusf at ix dot netcom dot com wrote:
There are some UTF-8/UTF-16 interoperability aspects that are
addressed by CESU-8. These concerns are real, and affect multi-
component architectures that must interchange data across component
John Cowan jcowan at reutershealth dot com wrote:
Most languages other than C define a string as a sequence of
characters rather than a sequence of non-null characters. The
repertoire of characters than can exist in strings usually has a lower
bound, but its full magnitude is
Asmus Freytag asmusf at ix dot netcom dot com wrote:
Let's drop this, or take it offline from here, shall we?
Consider it dropped.
-Doug Ewell
Fullerton, California
http://users.adelphia.net/~dewell/
A. Vine wrote:
FYI, we are well aware of this shortcoming (modified UTF-8), and with
each release try to mitigate it even further. The problem is that it is
so deep in the code (note that it is since Java 1.0) that it is not easy
to eliminate without breaking a lot of existing stuff, something
Theodore H. Smith scripsit:
I'm just curious about the \0 thing. What problems would having a \0 in
UTF-8 present, that are not presented by having \0 in ASCII? I can't
see any advantage there.
AFAICT it was a hack so that arbitrary Java strings could be encoded
as C strings; that is, with
From: A. Vine [EMAIL PROTECTED]
I'm just curious about the \0 thing. What problems would having a \0 in
UTF-8 present, that are not presented by having \0 in ASCII? I can't see
any advantage there.
Beats me, I wasn't there. None of the Java folks I know were there
either.
The problem is in the
http://java.sun.com/j2se/1.5.0/docs/api/java/io/
DataInput.html#modified-utf-8
If only people could sue for suggesting bad coding practices ;o)
--
Theodore H. Smith - Software Developer.
http://www.elfdata.com
FYI, we are well aware of this shortcoming (modified UTF-8), and with
each release try to mitigate it even further. The problem is that it is
so deep in the code (note that it is since Java 1.0) that it is not easy
to eliminate without breaking a lot of existing stuff, something that
the Java
I take your point that you are well aware of this. However some of your
users are not so aware, having read your information on Modified
UTF-8 and thinking hey, well is Sun do it, then it must be OK for me
to do it too!
This thread, was inspired by exactly that. Someone point me to this
page,
Theodore H. Smith wrote:
I take your point that you are well aware of this. However some of your
users are not so aware, having read your information on Modified UTF-8
and thinking hey, well is Sun do it, then it must be OK for me to do it
too!
Fair enough, it would be more helpful if you said
21 matches
Mail list logo
