Meeting Refactoring Requirements of J2EE^TM Developers

Refactoring gives developers the ability to transform their source code without affecting the semantics, and improve its readability or structure. The power of refactoring to transform badly written code into beautifully crafted pieces of software is well known. Today most Java developers are familiar with Java Refactoring. Of the large number of refactoring techniques that have been documented, Rename remains the most commonly used and affects large parts of the code. Having tools that can correctly and efficiently perform Rename operations reduces the reluctance among developers to revisit and improve the code. While such tools exist and are widely used, Java applications built for the J2EE framework need a lot more support.

What's special about J2EE

The complexity involved in J2EE development is considerably higher than just Java, as there are multiple file types such as JSPs and XMLs besides Java files that need to be changed. Then there are additional semantics associated with the source code that result from J2EE conventions. And finally, the metadata that refers to information in the source code. At the end of a refactoring run, all this information must reconcile as it did before refactoring. This is where J2EE refactoring helps.

J2EE refactoring is a layer of J2EE expertise added over the "plain vanilla" Java refactoring layer, making it one of the most powerful coding and maintenance tools for J2EE developers. Pramati Studio provides J2EE refactoring tools that achieve exactly this.

Significantly, Rename refactoring has been extended in Studio to cover all aspects of J2EE. At the end of refactoring, the application remains ready-to-deploy with all information transformed and in complete accordance with J2EE specifications. Further, since Pramati Studio supports multiple application servers J2EE refactoring in the IDE ensures that all necessary deployment information is updated so the application deploys on all supported servers straightaway.

Leveraging "Rename" for J2EE development

J2EE Rename kicks in when a user asks for a rename of an element. If the element is a J2EE artifact, or could potentially impact a J2EE artifact, it will ensure the necessary changes are made. Lets consider a couple of examples.

CMR Rename

The user asks one of the abstract getter or setter methods of a CMR to be renamed in a bean. J2EE refactoring understands the semantics of CMRs and asks for only the CMR name, rather than the method name, and changes:

1. the getter in the bean
2. the setter in the bean
3. the getter in the local if any
4. the setter in the local if any
5. the CMR in the bean properties XML file (Studio stores all metadata about a bean in a file called the Bean Properties)
6. the target role in the XML of the other bean, if the CMR is bi-directional
7. the JOIN condition mapping in the deployment XML, if there is a JOIN condition associated with this CMR.
8. the CMR name in all EJB-QLs of all the beans, where it appears in the right context

As this indicates, this is definitely a non-trivial task and is extremely error prone. J2EE refactoring makes this as simple as invoking "Java Refactoring".

Also since the deployment-time information, such as O-R Mapping (the JOIN condition in our example) has been changed, the application is ready-to-deploy at the end of the refactoring run.

Class Rename

The user asks for a Java class rename. Renaming a class which is not a J2EE artifact can have considerable and subtle impact on J2EE artifacts. For example, when a ValueObject class has been renamed, the old name could be mentioned in the ejb-jar.xml in one of the "method-param" tags, perhaps because the method set(ValueObject) had a method permission or a transaction attribute set against it. Java refactoring will not make changes to the meta-data in such a case. But J2EE refactoring in Studio will. On a class rename, Studio:

1. renames the Java class
2. changes all references in metadata from old class name to new class name
3. changes the Abstract Persistence Scheme (APS) name

Several such J2EE-specific operations are covered by Studio refactoring. Here is a brief list of these operations:

• CMF v1.1 Rename
• CMF v2.0 Rename
• CMR Rename
• Business Method Rename
• EjbHome Method Rename
• EjbSelect Method Rename
• Create Method Rename
• Finder Method Rename
• Class Rename
• Package Rename

What's Next

Support for J2EE refactoring in Pramati Studio is expanding, covering newer refactoring techniques and adding J2EE semantics to them. For example, the Change Method Signature technique will become J2EE-aware and Move will be leveraged for J2EE development.

Indeed, for J2EE developers refactoring makes it amazing to watch a complex application being sculpted into a completely new entity -- a work of art, you can say.