Am 22.09.2011 12:04, schrieb David Holmes:
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.
See quote from the original bug report
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7088952>:
"The most frequent use of the SIZE constant is to determine the storage space requiresments of the
type by Primitive.SIZE / Byte.SIZE"
So I would say, this bug is invalid.
The only reasonable use case/meaning seems to be to calculate footprint for serialization, which is
AFAIK Java language dependent. Then Boolean.BYTES would become unambiguous too. But then the
constants would better be defined java.io.DataOutput.
I'm additionally wondering, that a bug with state < accepted comes to process.
-Ulf
