aspose file tools*
The moose likes Java in General and the fly likes How are byte and short types stored internally? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "How are byte and short types stored internally?" Watch "How are byte and short types stored internally?" New topic
Author

How are byte and short types stored internally?

Avor Nadal
Ranch Hand

Joined: Sep 15, 2010
Posts: 86

Hello!:

I've a doubt regarding these primitive types. I've always treated both of them as real types. The tutorials from Sun/Oracle indeed explicitly indicate their bit length: 8 and 16 bit respectively. However, there are several signs which have made me think that they're treated internally as pure integers, and that byte/short differentiation is just to limit their values. For example they both haven't got a specific syntax to assign values, in contrast to long or float, which use the L and F letters to denote the type of value. Also, methods like DataOutputStream.writeByte () and writeShort () expect an integer as parameter, although they really write the exact amount of bits. Could it be possible that byte/short types are just limiters?

The only matter which have me intrigued is the fact that I read time ago that byte arrays save memory compared to integer arrays. What do you think about this matter? Thank you very much for your help.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36508
    
  16
Don't confuse int, Integer and integer. By "integer array" I presume you mean "int array".

All bytes, shorts, ints and longs are stored as two's complement signed binary integers. In older versions of Java™, the smaller types were indeed stored in 4-bytes words with empty space, but I believe they now occupy their correct number of bytes. byte[]s are popular because that is the easiest format for sending round a network.
Avor Nadal
Ranch Hand

Joined: Sep 15, 2010
Posts: 86

Campbell Ritchie: First of all, thanks for your answer ;) . When I mentioned "primitive types" I thought that I had made it clear that I didn't mean the object Integer. However, I agree that I should have stated int instead of integer, since the second concept is open to very different interpretations. So yes, I meant int. Sorry .

For your last sentence, I understand that Java really handles the right amount of bits for byte and short types nowadays, but never employed a 32-bit block like for int, Right? When I mention "handle", I mean during the execution, "behind the scenes", not when it persist the number to some kind of media (file, database, etc.).

In other words, if I executed something like this...

... the JVM would transform num1 from an 8-bit number to a 32-bit number internally. Is it correct?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18118
    
  39

Igor Nadal wrote:
In other words, if I executed something like this...

... the JVM would transform num1 from an 8-bit number to a 32-bit number internally. Is it correct?



When you try to compare two different primative types, one will be implicitly widen for the compare -- but this has nothing to do with how they will be stored.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36508
    
  16
. . . and if you do arithmetic, etc, in most instances the result is automatically expressed as an int, ie 32 bits.

I believe older versions of the JVM did in fact store a byte or a short in 32 bits, thereby wasting memory.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 13875
    
  10

How the JVM internally represents byte, short and other types, is an implementation detail of the JVM.

Some CPUs work more efficiently with 32-bit integers than with 8-bit or 16-bit integers, so a JVM for such a CPU might really be using 32 bits under the covers for these data types. And on other CPUs it might be different and this might not apply.

The bottom line is that in your Java program, byte and short will always look like 8-bit and 16-bit integers. How exactly the JVM stores those things in memory is not something that you need to be concerned with - the JVM does not expose such implementation details to your application.

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Avor Nadal
Ranch Hand

Joined: Sep 15, 2010
Posts: 86

Henry Wong: Well, I used the example of arithmetic operations just to check if someone (in this case Campbell) could tell me if a conversion happens or not internally. If a short is stored as an int, then no conversion will ever happen (I'm insisting, internally, not from the point of view of the application). That's the reason of that example. Anyway, Jesper clarified it. Thank you too.

Campbell Ritchie: That's what I wanted to know. Thanks.

Jesper de Jong: Very clarifying. Really this question was just for personal curiosity. I simply wanted to know the different treatment from the application's side (what we see when we program) in contrast to the JVM side. For example, I wanted to know if although we declared an array of type byte, the JVM would create an array of int internally. Obviously, since you say that it's implementation-dependant and not all the JVM do that, then one never know what will happen. Thank you a lot for your information. It's more clear now.
Ralph Cook
Ranch Hand

Joined: May 29, 2005
Posts: 479
Jesper de Jong wrote:How the JVM internally represents byte, short and other types, is an implementation detail of the JVM.

Some CPUs work more efficiently with 32-bit integers than with 8-bit or 16-bit integers, so a JVM for such a CPU might really be using 32 bits under the covers for these data types. And on other CPUs it might be different and this might not apply.

The bottom line is that in your Java program, byte and short will always look like 8-bit and 16-bit integers. How exactly the JVM stores those things in memory is not something that you need to be concerned with - the JVM does not expose such implementation details to your application.


I can imagine situations in which a programmer would need to know this. Say he was going to store a huge amount of information in memory, it would help to know how much memory, in general, a data structure takes up, rather than assuming that an array of bytes takes up less than an array of ints.

If it really is not exposed to the programmer in general, then I can see him wanting to know how one or more JVMs implements it.

I guess what I'm saying is that this is not a detail in all programming situations, because we still have machines with finite, and sometimes limited, memory.

rc
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How are byte and short types stored internally?
 
Similar Threads
Marcus Green - What is Java Integral Type
What happens during casting
Confusion creating String
Wrappers
Implicit vs explicit numeric promotion