In the book of P. Nouton, G. Shildt "Java 2. The most complete guide" says the following about the size of data types:

The width (or the number of bits allocated for storing values) of an integer type cannot be thought of as the amount of memory it occupies, but rather, as the behavior that it defines for variables and expressions of this type. The Java runtime is free to use whatever size it wants, while the types behave according to their declaration. There is at least one implementation of the execution environment that stores the byte and short numbers as 32-bit (not 8-bit and 16-bit) values ​​to improve efficiency, because this value expresses the word size of most computers currently used.

Elsewhere in this book it says:

It may seem that using short or byte saves memory, but there is no guarantee that Java will not internally somehow extend these types to int . Remember that type determines behavior, not size. (The only exception is arrays, where the type byte guarantees the use of only one byte per array element, while short will take two bytes and int - four bytes).

In connection with the above, I had a question: what is meant by the word behavior of variables of integer type and is it true that for variables not declared as arrays, the size is not defined?

  • [italics indicates the most important thing] [1] [1]: habrahabr.ru/en/post/76481 - Viacheslav
  • @Viacheslav, 15GB RAM and 5 hours to launch the application - amused. I wonder where these customers are found? - avp

2 answers 2

I suppose in this case we are entering into an eternal conflict: we want to think of types as behavior (at the level of logic), but being very limited in resources, we also have to think about the amount of allocated memory. As a result, compromise variants and compromise approaches are born to think about them.

For example, at the time of C, according to the standard, only relations of the type short int <= int <= long int existed, everything else was specific to a particular platform. This is a very shaky state of affairs, which was taken into account in the design of Java.

The Java Language Specification standard clearly defines extreme values ​​for types, that is, the minimum bitness at the physical level. For example, long should operate with 64-bit values, even if the underlying hardware platform does not know how.

Anyone can write their own "implementation" of the JVM or the Java language, but if the result does not satisfy the specification, it is no longer possible to call it "Java", the specification is all about the technology. You can consider problems with such "implementations", but it is important to distance yourself from them, because these are no longer problems of the Java platform, but problems of some third-party solution.

Can this be used somehow to determine the real iron performance? For example, on a 32-bit machine, long, relatively speaking, it will be physically represented by two inta, that is, the code for working with longs will be slower. On the other hand, when switching to a 64-bit system, the program itself starts working slower (up to 20% on SPARC, 0-15% on AMD64 and EM64T) at least because of the size of the pointer that is increased from 4 to 8 bytes. In other words, everything is difficult.

In the simple case, it is more correct to keep in mind that the size of a primitive type is behavior (a guarantee for ranges of values ​​and the fact that between the platforms the logic of working with them will not fall apart). But remember that, ultimately, this is an engineering compromise, stitched inside the standard, with which in especially serious cases you will have to do something.

    Apparently, the behavior of the authors understand how to work with this type of data, what are its limits, how to convert, etc.

    Regarding the second question: you need to know that there are several implementations of a virtual machine (it is abbreviated as JVM) from different companies. And so in different JVM at code performance:

     int i = 1;

    The variable i can be either 4 or 8 bytes. And it depends on the implementation of the JVM.

    My IMHO and experience suggest - as long as you do not write programs that work with millions of entries, you should not bother with this much. It is better to learn programming in java as a whole. When you come to the point where the programs will be large, you will already know what to do with it and how to profile the code.