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

David Holmes david.holmes at oracle.com
Thu Sep 22 21:34:21 UTC 2011

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/viewbug.do?bugid=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

More information about the core-libs-dev mailing list