BlanK Finals,Reflection in java

Blank Finals:-
As we know that local variables, method parameters, and exception parameters of catch statements may be declared final. A related change is that final fields do not require initializers. In Java 1.0, any final field had to be initialized as part of the field declaration. In Java 1.1, this restriction has been relaxed. A field or local variable can be declared final without specifying an intial value as part of the declaration. These "blank finals," as they are called, must have a value assigned to them before they are ever used, of course. And, once a value has been assigned to a blank final, that value can never be changed. This allows you, for example, to use an instance initializer or a constructor to compute a value for a final field.
Blank finals are particularly useful in defining immutable data types. They allow a class to have immutable fields that are initialized based on run-time arguments to a constructor. Once assigned, these fields cannot be accidentally or maliciously changed.

Reflaction:-
Reflection in Java 1.1 refers to the ability of Java classes to reflect upon themselves, or to "look inside themselves." The java.lang.Class class has been greatly enhanced in Java 1.1. It now includes methods that return the fields, methods, and constructors defined by a class. These items are returned as objects of type Field, Method, and Constructor, respectively. These new classes are part of the new java.lang.reflect package, and they each provide methods to obtain complete information about the field, method, or constructor they represent. For example, the Method object has methods to query the name, the parameter types, and the return type of the method it represents.
Besides allowing a program to inspect the members of a class, the java.lang.reflect package also allows a program to manipulate these fields and methods. The Field class defines methods that get and set the value of the represented field for any given object of the appropriate type. Similarly, the Method object defines an invoke() method that allows the represented method to be invoked, and the Constructor class defines a newInstance() method that creates a new object and invokes the represented constructor on it. java.lang.reflect also defines an Array class. It does not represent a specific array, but defines static methods that read and write array elements and dynamically create new arrays.
With the addition of reflection, the Class class has been expanded to represent not just Java classes, but any Java type, including primitive types and array types. There is a special Class object that represents each of the eight Java primitive types, and another special Class object that represents the void type. These special Class objects are available as constants in the wrapper objects for the primitive types. Integer.TYPE is a Class object that represents the int type, for example, and Void.TYPE is a Class object that represents the void type.

Applets in JAVA

Applet class can be used to enhance the way your applet works. Recall that the Applet class provides the foundation for creating applets-Java applications that run in a browser environment. Besides launching your applet, the Applet class provides many useful services. It can be used to load image and audio files, work with URLs, and access the native browser environment. Since the Applet class is also a component of the AWT package .Applet objects provide many of the visual features that are part of the standard AWT repertoire, especially using the Graphics class for painting text, shapes, and images. Since The Applet class is a subclass of the AWT Component class, it can handle events such as mouse events and keystrokes.
Four often misunderstood Applet methods are overridden to manage the life cycle of an applet. None of these methods are required to be overridden, although their use will generally give you a more stable applet. These are the four methods:

init() This is used to initialize an applet whenever it is loaded. You typically override this method to set up resources that will be used throughout an applet, such as fonts, or to initialize variables. This method is called once and only once during the lifetime of your applet. However, if the applet is reloaded for some reason or another, the init() method will be called again. Some Java literature may lead you to believe that you have to always override this method. This is not true! You need to override init() only when your applet's circumstances dictate that you should. A good example of this is initializing resources, such as AWT components.

start() This is called whenever the HTML document on which an applet resides becomes the current page of a browser. When an applet is first run, the start() method is called after init(). Unlike the latter, however, start() will be called whenever the user visits the applet's page. Two very important types of activities should be located in the start() method. The show() method of instances of the Frame class are best called in the start() method. Since Frames occur outside the confines of an applet page, they will stay onscreen even after you have left the page. Consequently, they should be shown when you enter the page and hidden when you leave (see the stop() description method that follows). There will be an example in the upcoming listings. The start() method is also a good place to begin threads since their existence is also not confined to the page where they began.

stop() This method is called whenever the user leaves a page-it is the converse of the start() method. Therefore, it's a good place to hide frames and terminate threads.

destroy() The destroy() method is called whenever the applet is being shut down. Typically, this will occur when the browser is being closed, although there could be other circumstances that could lead to destroy() being invoked. This method is a good place to do some cleanup. However, since it's unpredictable when destroy() will be called, it should be used with some discretion.