Recommended: Sing it, brah! 5 fabulous songs for developers
JW's Top 5
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
Complex applications usually have many initialization problems that a developer must solve. A number of different steps prove necessary to set up a panel, to configure a service, etc. To make things even more difficult, some of those steps must be repeated, others do not. To put this kind of management into the class itself is troublesome because the logic might change. In addition, modern software design urges the separation of responsibilities. In short, the goal is to separate the logic of what is done from how it is done.
This article shows you how to use annotations beyond simple markings for initialization control. It introduces a small API that you can use to develop your own "phaseable" annotations and gives you some inspiration concerning this new feature's possibilities.
An annotation is a new language feature introduced in J2SE 5.0. Simply put, annotations allow developers to mark classes, methods, and members with secondary information that is not part of the operating code. This allows, for instance, a rating like "good method," "bad method," or, more adequately, "deprecated method" or "overridden method." The possibilities are endless. Note that it is irrelevant what the method or class actually does when it is marked as "deprecated," for example. For a more detailed discussion of annotations, see Java 5.0 Tiger: A Developer's Notebook.
Since annotations can be used to describe the usage and meaning of entities like methods and classes, they are, loosely put, a sort of semantic sugar. In turn, this additional information can be evaluated by others (e.g., frameworks) and used for all kinds of actions, like generating documentation (Javadoc) or, as discussed here, for controlling behavior like the lifecycle of objects in specific contexts.
Lifecycle management usually occurs in middleware environments like application servers. The idea is to separate the logic of on object's construction, usage, and destruction from the object itself. In an application server, for example, where different services are published, it doesn't usually matter what particular service is requested; the mechanism of invoking the service within the application server follows a more or less identical scheme. Depending on the state of the application, the caller, and other parameters, some variation might prove necessary, but in a manageable environment, the basic algorithm will follow a sequential chain of operations. In Java client applications, for instance, it is necessary to manage the display of masks or forms that allow the user to enter or alter application data.
In Java applications, masks are used for data collection and manipulation—data handling often referred to as the CRUD (create, read, update, delete) cycle. The user is presented some data that can be altered, deleted, or newly entered. As a simple business problem, we want to manage how masks display in a client application. Thus, we separate the display into a chain of operations like this:
Archived Discussions (Read only)