Review Request: 7088913/7088952 : Additions to primitive wrappers (original) (raw)

Ulf Zibis Ulf.Zibis at gmx.de
Thu Sep 22 09:40:05 UTC 2011

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

More information about the core-libs-dev mailing list