|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
When I think about Java's support for runtime class information, two clichés come to my mind:
1. Information is power.
In our case, runtime class information gives power to the programmer because he or she has more information to work with. This is a good thing.
2. Power corrupts.
Alas, in our case, runtime class information can be abused in designs.
The question I attempt to answer in this article is: How can you take advantage of the cool runtime class information offered by Java objects without being accused of abuse of power?
Before I delve into guidelines, I'd like to give you some background on how runtime class information works in Java.
Every class or interface you write in the Java programming language defines a new type for your program to use. Once you define a new type, you can declare variables of that type. A type defines a set of operations that may be performed on variables of that kind and the meaning of those operations.
If you define a class Hippopotamus, for example, you then can declare variables of type Hippopotamus. On such variables, the Java virtual machine (JVM) will allow you to perform operations defined for type Hippopotamus, but won't allow any other operations. If class Hippopotamus declares a public takeBath() method, for example, the JVM will allow you to invoke takeBath() on a variable of type Hippopotamus.
When you compile your class or interface, the Java compiler (if it is fully pleased with your work) will give you a class
file. The class file is an intermediate-compiled binary format for describing a Java type (a class or interface). The class
file for Hippopotamus, for example, would contain all information needed to define that type, including things like:
Hippopotamus)
public or abstract)
static, abstract, private, and so on)
When a JVM loads a type (a class or interface), the JVM stores information about that type in a logical portion of its memory called the method area. The type information stored in the method area corresponds to the information stored in the class file, but unlike the class file, the structure and organization of the information in the method area is not defined by the Java specifications. The designers of each JVM decide how to store the information they parse from Java class files in the method area of their JVM implementation.