You must create all the objects

all
the objects

When

you create a handle, you want to connect it with a new object. You do so, in

general, with the

keyword.

says, “Make me a new one of these objects.” So in the above

example, you can say:

Not

only does this mean “Make me a new

,”

but it also gives information about

to make the

by supplying an initial character string.

Of

course,

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 book.

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:

1. Registers.
   This is the fastest storage because it exists in a place different than 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.
2. 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 handles
   – Java objects are not placed on the stack.
3. 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. And of course
   there’s a price you pay for this flexibility: it takes more time to
   allocate heap storage.
4. 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.
5. 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).
6. 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 1.1
   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

,

especially a small, simple variable, isn’t very efficient because

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

,

an “automatic” variable is created that

.

The variable holds the value, and it’s placed on the stack so it’s

much more efficient.

Java

determines the size of each primitive type. These sizes don’t change from

one machine architecture to another as they do in most languages. This size

invariance is one reason Java programs are so portable.

All

numeric types are signed, so don’t go looking for unsigned types.

The

primitive data types also have “wrapper”

classes

for them. That means that if you want to make a non-primitive object on the

heap to represent that primitive type, you use the associated wrapper. For

example:

Character
C = new Character(c);

or

you could also use:

The

reasons for doing this will be shown in a later chapter.

High-precision
numbers

Java

1.1

Both

classes have methods that provide analogues for the operations that you perform

on primitive types. That is, you can do anything with a

or

that

you can with an

or

,

it’s just that you must use method calls instead of operators. Also,

since there’s more involved, the operations will be slower. You’re

exchanging speed for accuracy.

supports arbitrary-precision integers. This means that you can accurately

represent integral values of any size without losing any information during

operations.

is for arbitrary-precision fixed-point numbers; you can use these for accurate

monetary calculations, for example.

Consult

your online documentation for details about the constructors and methods you

can call for these two classes.

Arrays
in Java

Virtually

all programming languages support arrays. Using arrays in C and C++ is perilous

because those arrays are only blocks of memory. If a program accesses the array

outside of its memory block or uses the memory before initialization (common

programming errors) there will be unpredictable results.

One

of the primary goals of Java is safety, so many of the problems that plague

programmers in C and C++ are not repeated in Java. A Java array is guaranteed

to be initialized and cannot be accessed outside of its range. The range

checking comes at the price of having a small amount of memory overhead on each

array as well as verifying the index at run time, but the assumption is that

the safety and increased productivity is worth the expense.

When

you create an array of objects, you are really creating an array of handles,

and each of those handles is automatically initialized to a special value with

its own keyword:

You

can also create an array of primitives. Again, the compiler guarantees

initialization because it zeroes the memory for that array.

Arrays

will be covered in detail in later chapters.

In Java version 1.1 only, not in 1.0.

In C++ you should often use the safer containers in the Standard Template

Library as an alternative to arrays.

|

|