On 22/09/2011 7:40 PM, Ulf Zibis wrote:
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)
I can support the SIZE == resolution position.
But BYTES can't mean "memory usage" as that is totally VM dependent and
also has platform dependencies, and is not a constant as such due to the
way different fields can be packed together.
The constants are Java language constants, not VM related, so I think
that both SIZE and BYTES have to be resolution. Which still means to me
that for boolean BYTES is ambiguous enough to be worth leaving out.
... 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.
According to the VM spec booleans map to ints (Ref 3.11.1). But the VM's
native representation could use bit-fields for booleans.
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. ;-)
I'm tempted to make a tongue-in-cheek comment about adding lambdas, but
I'll resist the temptation ;-)
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.
But given that you can't calculate "footprint" this way the point seems
somewhat moot.
Cheers,
David
hat
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
