Review Request: 7088913/7088952 : Additions to primitive wrappers

Ulf Zibis Ulf.Zibis at
Sat Sep 24 00:32:47 UTC 2011

Am 24.09.2011 01:57, schrieb Mike Duigou:
> On Sep 22 2011, at 14:34 , David Holmes wrote:
>> 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
>>> <>:
>>> "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?
> For cases like DataOutputStream where manifest constants are currently used. The same could apply in NIO byte buffers as well as user code.
As I said, I would say, such constant would belong to DataOutput(Stream) and/or NIO package, rather 
than to the Java type.

> It's also useful for calculating the size of arrays of primitives (with the exception of boolean).
As David said, this is dependent of the VM implementation.
But I would support methods, which retrieve the actual values from the VM.


More information about the core-libs-dev mailing list