Review Request: 7088913/7088952 : Additions to primitive wrappers

[David Holmes]

On 22/09/2011 11:23 PM, Ulf Zibis wrote:
> 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.

I'm inclined to agree at the moment.

Mike: exactly what kind of "storage space requirements" were you 
considering?

David
------


> 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