«

Mike Schilling wrote:

> I believe that the existing mess could have been avoided with precisely
> one change to the existing definition of Java: rather than define a char
> as a 16-bit integral type, define it as a non-integral type of an
> unspecified size. (Exactly like boolean.)

Of even as an unsigned integral type with a size guaranteed to be <= 31 bits.

There would have to have been small changes to the JVM spec, and to the
serialisation spec too (and to JNI -- though that didn't come out until later).
But nothing of staggering difficulty. Even the JVM /implementation/ would be
largely unchanged since chars are represented in 32-bit slots on the stack
anyway...

.... sigh ...

-- chris

Chris Uppal wrote:
> Mike Schilling wrote:
>
>> I believe that the existing mess could have been avoided with
>> precisely one change to the existing definition of Java: rather
>> than define a char as a 16-bit integral type, define it as a
>> non-integral type of an unspecified size. (Exactly like boolean.)
>
> Of even as an unsigned integral type with a size guaranteed to be <=
> 31 bits.

I considered that, but didn't see a definite need for even that loose
guarantee. (Why 31 and not 32, by the way? What makes the guarantee
useful, I think, is that chars can be losslessly converted to ints.)

Mike Schilling wrote:
> Chris Uppal wrote:
>> Mike Schilling wrote:
>>
>>> I believe that the existing mess could have been avoided with
>>> precisely one change to the existing definition of Java: rather
>>> than define a char as a 16-bit integral type, define it as a
>>> non-integral type of an unspecified size. (Exactly like boolean.)
>>
>> Of even as an unsigned integral type with a size guaranteed to be <=
>> 31 bits.
>
> I considered that, but didn't see a definite need for even that loose
> guarantee. (Why 31 and not 32, by the way? What makes the guarantee
> useful, I think, is that chars can be losslessly converted to ints.)

Oh, "unsigned". Never mind.

Chris Uppal wrote:
> Mike Schilling wrote:
>> I believe that the existing mess could have been avoided with precisely
>> one change to the existing definition of Java: rather than define a char
>> as a 16-bit integral type, define it as a non-integral type of an
>> unspecified size. (Exactly like boolean.)
>
> Of even as an unsigned integral type with a size guaranteed to be <= 31 bits.
>
> There would have to have been small changes to the JVM spec, and to the
> serialisation spec too (and to JNI -- though that didn't come out until later).
> But nothing of staggering difficulty. Even the JVM /implementation/ would be
> largely unchanged since chars are represented in 32-bit slots on the stack
> anyway...

For proper interoperability it has to be specified what it is.

Arne

Arne Vajhøj wrote:
> Chris Uppal wrote:
>> Mike Schilling wrote:
>>> I believe that the existing mess could have been avoided with
>>> precisely one change to the existing definition of Java: rather
>>> than define a char as a 16-bit integral type, define it as a
>>> non-integral type of an unspecified size. (Exactly like boolean.)
>>
>> Of even as an unsigned integral type with a size guaranteed to be <=
>> 31 bits. There would have to have been small changes to the JVM spec, and
>> to
>> the serialisation spec too (and to JNI -- though that didn't come
>> out until later). But nothing of staggering difficulty. Even the
>> JVM /implementation/ would be largely unchanged since chars are
>> represented in 32-bit slots on the stack anyway...
>
> For proper interoperability it has to be specified what it is.

Or, to be precise, how it's represented externally. This could be, for
instance, as the character's UTF-8 representation.

Arne Vajhøj wrote:

[me:]
> > There would have to have been small changes to the JVM spec, and to the
> > serialisation spec too (and to JNI -- though that didn't come out until
> > later). But nothing of staggering difficulty. Even the JVM
> > /implementation/ would be largely unchanged since chars are represented
> > in 32-bit slots on the stack anyway...
>
> For proper interoperability it has to be specified what it is.

We were considering what changes would have been necessary back at the
beginning of Java's history for this UTF-16 mess to have been avoided, or
avoidable. I agree that we are in fact stuck with what we've got.

Way back then there was no interoperability, since there was nothing to
interoperate /with/

-- chris

Chris Uppal wrote:
> Arne Vajhøj wrote:
> [me:]
>>> There would have to have been small changes to the JVM spec, and to the
>>> serialisation spec too (and to JNI -- though that didn't come out until
>>> later). But nothing of staggering difficulty. Even the JVM
>>> /implementation/ would be largely unchanged since chars are represented
>>> in 32-bit slots on the stack anyway...
>> For proper interoperability it has to be specified what it is.
>
> We were considering what changes would have been necessary back at the
> beginning of Java's history for this UTF-16 mess to have been avoided, or
> avoidable. I agree that we are in fact stuck with what we've got.
>
> Way back then there was no interoperability, since there was nothing to
> interoperate /with/

It is not backwards compatibility I am talking about.

I am talking about interoperability between JVM's from
different vendors.

If you have a SUN and IBM Java exchanging binary data, then
it is very beneficial that the number of bits in a char is
well defined - not at least X bits as we all know it from C/C++.

Arne

Arne Vajhøj wrote:

[me:]
> > We were considering what changes would have been necessary back at the
> > beginning of Java's history for this UTF-16 mess to have been avoided,
> > or avoidable. I agree that we are in fact stuck with what we've got.
> >
> > Way back then there was no interoperability, since there was nothing to
> > interoperate /with/
>
> It is not backwards compatibility I am talking about.
>
> I am talking about interoperability between JVM's from
> different vendors.
>
> If you have a SUN and IBM Java exchanging binary data, then
> it is very beneficial that the number of bits in a char is
> well defined - not at least X bits as we all know it from C/C++.

Ah, I had misunderstood you. Sorry.

But I don't think it would have been possible to allow for binary compatibility
(in that sense) /and/ had the Java spec worded in such a way that it didn't
make it impossible to fix up future problems.

At least, not without buildng extra (explicit) flexibility into each binary
spec.

-- chris

"Chris Uppal" <> wrote in message
news:45dc303b$0$765$...
> Arne Vajhøj wrote:
>
> [me:]
>> > We were considering what changes would have been necessary back at the
>> > beginning of Java's history for this UTF-16 mess to have been avoided,
>> > or avoidable. I agree that we are in fact stuck with what we've got.
>> >
>> > Way back then there was no interoperability, since there was nothing to
>> > interoperate /with/
>>
>> It is not backwards compatibility I am talking about.
>>
>> I am talking about interoperability between JVM's from
>> different vendors.
>>
>> If you have a SUN and IBM Java exchanging binary data, then
>> it is very beneficial that the number of bits in a char is
>> well defined - not at least X bits as we all know it from C/C++.
>
> Ah, I had misunderstood you. Sorry.
>
> But I don't think it would have been possible to allow for binary
> compatibility
> (in that sense) /and/ had the Java spec worded in such a way that it
> didn't
> make it impossible to fix up future problems.
>
> At least, not without buildng extra (explicit) flexibility into each
> binary
> spec.

That is, Java wouldn't define a binary format for chars; chars would be
exchanged (as Strings are) via some encoding of chars into bytes.