Review Request: 7088913/7088952 : Additions to primitive wrappers

[Ulf Zibis]

Am 22.09.2011 01:54, schrieb Mike Duigou:
> I will create a request to add Boolean.SIZE though I am not sure adding a Boolean.BYTES is appropriate for something less than Byte.Size in size. Is it 1-bit? Is it 1-byte? The answer is dependant upon usage and I don't think we can force a single answer.
>
> Mike
>
> On Sep 21 2011, at 03:36 , Ulf Zibis wrote:
>
>> Hi,
>>
>> why don't we have Boolean.SIZE and Boolean.BYTES ?
>>
>> -Ulf
Yep, not easy to make a right decision here.

One if the questions might be, if SIZE/BYTES are meant as resolution (2**SIZE = number of distinct 
values) or as memory usage.
I would say: SIZE should be meant as resolution, but BYTES as memory usage. This would add 
additional value to the new introduced constant.
So:
Boolean.SIZE = 1
Boolean.BYTES = 4     (8 for 64-bit build)


> ... At the VM level they map to ints.
This is not always true. Arrays of byte are mapped to byte[] in VM. For boolean, it's theoretically 
possible to map a boolean[32] to one int.

>
> For that matter I'm not sure the addition of BYTES is worth the effort.
Yes or not, I'm unsure. My first feeling was, there _must_ be some additional APIs to justify the 
change to a new release, here 8. ;-)
But I think, it's reasonable to have a short cut when calculating the footprint of some data, 
instead repeating SIZE/Bytes.SIZE in code. That said, there should be a clear definition, if BYTES 
is meant as VM-memory-footprint or persistent-storage-footprint e.g. by serialization, or we should 
have three:
MEM_BYTES
ARRAY_MEM_BYTES
SERIALIZATION_BYTES

-Ulf