Rational Application Developer for WebSphere Software version 6.0 includes some awesome tools for doing automated code review that I've started to use on migration engagements. As part of a migration assessment, I take a look through the application code to determine what--if anything--needs to be changed. While I'm looking through the code, I try to make an assessment of how closely the code conforms to established best practices. This is where the code review tools come in handy.
Code review looks for certain patterns in the code. It will, for example, detect if resources like JDBC connections are not explicitly closed (it is a best practice to open and close these kinds of resources in the same method). It also looks for code complexity (e.g. too many nested 'if's, or too many operators in conditional statements).
For many rules a "quick fix" feature is available that will actually update your code to apply the best practice. "Quick Fix" is a new feature that's part of Eclipse 3.0; by putting your cursor over a problem in the Java editor and hitting "ctrl-1", a menu of quick fix options are presented.
You can define your own rules for the code review. I'm planning to add some migration rules so the code review process can find such things as the use of proprietary APIs. Unfortunately, I haven't sorted out (yet) how to add rules that look for specific string patterns; I could use this to find initial context factory names and URL strings that are particular to a competitive application server. Oh well, at least I now have a regular-expression search facility which should help take care of that.
If you haven't already tried it, you should take a look at the code review feature. It's easy to use: just highlight your project and select "Code Review > Review [project name]" from the context menu. Visit the Preferences window's "Java > Code Review" page to customize the review process. You can use this page to select a subset of the rules to run (this is particularly helpful since running a full review is pretty time consuming).
For more information about the Code Review tools in Rational Application Developer, please see Overview of static analysis in IBM Rational Application Developer 6.0.[Read More]
Eclipse hints, tips, and random musings
Wayner 1000002UYQ 215 Visits
The WebSphere Application Server version 6.0 InfoCenter includes a section titled "Migrating, coexisting, and interoperating" which provides (oddly enough) information on what you should expect while migrating your applications and environment to .
The Deprecated features in Version 6.0 page shows a list of feature that were available in previous versions of WebSphere Application Server but are now deprecated. Conveniently, it also lists features that were deprecated in previous versions. The page provides a description of the deprecated feature and the action you should take to migrate any code or configuration that depends on the feature.
Note that "deprecation" basically means that the feature will go away but is still supported today. You should use this as a warning and plan to update your code and runtime configuration as a natural part of the evolution of your application.
If you're planning a migration, there may be other issues to consider. Bobby Woolf, in a recent blog entry titled "Can't Use MessageListeners in J2EE" described a restriction in the J2EE 1.3 (and J2EE 1.4) specification that forbids the use of JMS MessageListeners in the servlet and EJB containers. If you're migrating from WebSphere Application Server versions 3.5 or 4.0, then this may affect you. Strictly speaking, this is not a deprecation (and is not listed in the InfoCenter deprecations page) since use of MessageListeners is never explicitly mentioned by the J2EE 1.2 specification.
I am in the process of ferreting out other issues that will affect your migration to WebSphere Application Server version 6.0 and will report on them in future blog entries.[Read More]
Wayner 1000002UYQ 281 Visits
In what is destined to become an epic blog series, I have been discussing some client code that had been intended to introduce loose coupling into an application (see my posts of Feb. 17th and 18th). I've argued that the code does not actually decouple anything since the business logic still depends on the existence of the GUI code. But how do you actually decouple the business logic from the GUI?
One way is to use an exception. Build your own exception using domain-specific language and have your controller--whatever form that controller takes--handle the exception. So, instead of a business method that looks like this:
Try something like this:
You can load up the exception with all kinds of information if you need to. In this case, only the error message itself is included, but you could add other information to the exception that will--naturally--be passed to handlers of the exception.
The exception handler in the client code might look something like this:
The client of the business logic (in this case, some GUI code) can decide how best to handle the error. By using the exception, you completely decouple the business logic from the particular view or controller. It's decoupled, because the business logic now knows nothing about the outside world. This is a good thing.
Don't be afraid to create new exception types for your application. But make sure it makes sense. Some of the bigger messes I've seen are a result of using too much of a good thing.
There are other ways to decouple the code, but I'll save them for another day.[Read More]
Wayner 1000002UYQ 230 Visits
In yesterday's post, I showed some code that I encountered while doing a migration assessment for a customer. I'll wait a few minutes while you go back and review...
My client chose this implementation to "decouple" their model code (what I've been referring to as "business logic") from their GUI. Unfortunately, this isn't what they got. Wikipedia defines "coupling" as the "degree to which each program module relies on each other module," and then goes on to provide some discussion of how coupling is measured. What this breaks down to is how much does--in this example--the business logic depend on the GUI code. The answer is "quite a lot".
Think about it in these terms: if the GUI layer goes away (i.e. is replaced by some other form of user interface), does the business logic break? In our example, the answer is yes, so this is actually an example of tight coupling.
What the code does do is introduce what I'm going to call "really late binding".
So how do we fix this? Well... I need to leave something for tomorrow.[Read More]
While reviewing a client's code recently to determine the effort required to migrate them to WebSphere Application Server, I stumbled upon the following code embedded inside an class in the business logic layer:
(I have, of course, modified the code to protect the identity of the client)
The main reason for writing the code using the reflection APIs is to--as the comment suggests--decouple the the business logic from the display logic. Clearly, the business logic needs to print a message to the user, but to directly reference the class would introduce a tight coupling between the business logic and the GUI which we all know is bad.
Unfortunately, this sort of use of the reflection API does not decouple the application. This merely makes it so that the business logic code can compile without the GUI code being visible to the compiler. This is really nothing more than a compiler trick.
The resulting code is still just as tightly coupled as the equivalent "regular Java" code:
At runtme, the business logic layer depends on the GUI code. The business logic is looking for a particular method on a particular class. Using the reflection API has changed nothing.
Tomorrow, I'll talk about how we know if something is tightly coupled and why we care.[Read More]