Everything is an object, Part 1
Learn to write your first Java program with these Java basics
By Bruce Eckel, JavaWorld.com, 09/08/00
- Digg
- Reddit
- SlashDot
- Stumble
- del.icio.us
- Technorati
- dzone
Page 2 of 7
String s = new String("asdf");
Not only does this mean "Make me a new String," but it also gives information about how to make the String by supplying an initial character string.
Of course, String is not the only type that exists. Java comes with a plethora of ready-made types. What's more important is that you can create
your own types. In fact, that's the fundamental activity in Java programming, and it's what you'll be learning about in the
rest of this [article].
Where storage lives
It's useful to visualize some aspects of how things are laid out while the program is running, in particular how memory is
arranged. There are six different places to store data:
- Registers. This is the fastest storage because it exists in a place different from that of other storage: inside the processor. However,
the number of registers is severely limited, so registers are allocated by the compiler according to its needs. You don't
have direct control, nor do you see any evidence in your programs that registers even exist.
- The stack. This lives in the general RAM (random-access memory) area, but has direct support from the processor via its stack pointer. The stack pointer is moved down to create new memory and moved up to release that memory. This is an extremely fast and
efficient way to allocate storage, second only to registers. The Java compiler must know, while it is creating the program,
the exact size and lifetime of all the data that is stored on the stack, because it must generate the code to move the stack
pointer up and down. This constraint places limits on the flexibility of your programs, so while some Java storage exists
on the stack-in particular, object references -- Java objects themselves are not placed on the stack.
- The heap. This is a general-purpose pool of memory (also in the RAM area) where all Java objects live. The nice thing about the heap
is that, unlike the stack, the compiler doesn't need to know how much storage it needs to allocate from the heap or how long
that storage must stay on the heap. Thus, there's a great deal of flexibility in using storage on the heap. Whenever you need
to create an object, you simply write the code to create it using
new, and the storage is allocated on the heap when that code is executed. Of course there's a price you pay for this flexibility:
it takes more time to allocate heap storage than it does to allocate stack storage (that is, if you even could create objects on the stack in Java, as you can in C++).
- Static storage. "Static" is used here in the sense of "in a fixed location" (although it's also in RAM). Static storage contains data that
is available for the entire time a program is running. You can use the static keyword to specify that a particular element
of an object is static, but Java objects themselves are never placed in static storage.
- Constant storage. Constant values are often placed directly in the program code, which is safe since they can never change. Sometimes constants
are cordoned off by themselves so that they can be optionally placed in read-only memory (ROM).
- Non-RAM storage. If data lives completely outside a program it can exist while the program is not running, outside the control of the program.
The two primary examples of this are streamed objects, in which objects are turned into streams of bytes, generally to be sent to another machine, and persistent objects, in which the objects are placed on disk so they will hold their state even when the program is terminated. The trick with
these types of storage is turning the objects into something that can exist on the other medium, and yet can be resurrected
into a regular RAM-based object when necessary. Java provides support for lightweight persistence, and future versions of Java might provide more complete solutions for persistence.
Special case: primitive types
There is a group of types that gets special treatment; you can think of these as "primitive" types that you use quite often
in your programming. The reason for the special treatment is that to create an object with new --especially a small, simple variable -- isn't very efficient because new places objects on the heap. For these types Java falls back on the approach taken by C and C++. That is, instead of creating
the variable using new, an "automatic" variable is created that is not a reference. The variable holds the value, and it's placed on the stack so it's much more efficient.
- Digg
- Reddit
- SlashDot
- Stumble
- del.icio.us
- Technorati
- dzone