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
One of Java's strengths is that it was designed with the assumption that the environment in which it was running would be changing dynamically. Classes are loaded dynamically, binding is done dynamically, and object instances are created dynamically on the fly when they are needed. What has not been very dynamic historically is the ability to manipulate "anonymous" classes. In this context, an anonymous class is one that is loaded or presented to a Java class at run time and whose type was previously unknown to the Java program.
Supporting anonymous classes is hard to explain and even harder to design for in a program. The challenge of supporting an anonymous class can be stated like this: "Write a program that, when given a Java object, can incorporate that object into its continuing operation." The general solution is rather difficult, but by constraining the problem, some specialized solutions can be created. There are two examples of specialized solutions to this class of problem in the 1.0 version of Java: Java applets and the command-line version of the Java interpreter.
Java applets are Java classes that are loaded by a running Java virtual machine in the context of a Web browser and invoked.
These Java classes are anonymous because the run time does not know ahead of time the necessary information to invoke each
individual class. However, the problem of invoking a particular class is solved using the Java class
Common superclasses, like
Applet, and Java interfaces, like
AppletContext, address the problem of anonymous classes by creating a previously agreed upon contract. Specifically, a runtime environment
supplier advertises that she can use any object that conforms to a specified interface, and the runtime environment consumer
uses that specified interface in any object he intends to supply to the run time. In the case of applets, a well-specified
interface exists in the form of a common superclass.
The downside of a common superclass solution, especially in the absence of multiple inheritance, is that the objects built
to run in the environment cannot also be used in some other system unless that system implements the entire contract. In the
case of the
Applet interfaces, the hosting environment has to implement
AppletContext. What this means for the applet solution is that the solution only works when you are loading applets. If you put an instance
Hashtable object on your Web page and point your browser to it, it would fail to load because the applet system cannot operate outside
its limited range.