Java

This is my first article in the month of June after a break from the last which I have written in March. There is a bug (and there still is) with my WordPress installation where i cannot embed codes (Java codes etc.) anymore.

Have you ever been part of a project where there is little governance over what developers put into session, and to make things worse, there are no standards (in my project this would be primarily my fault because I kept delaying on the deliverable for a standards document :p) to call for what is an acceptable session variable name.

This is quite pertinent to happen in a tightly funded maintenance project where the objective has been to extend the lifespan of an aging legacy application while waiting for newer applications to be built to take over its roles and functionality.

This article covers the topic on the difficulty to track and know the session variables that developers have put into session. (In my project developers introduce at an alarming rate of 20 new session attributes per release)

(Hint JSF developers, you don’t have to be reading this unless your project has been abused, Struts 1/2 developers, read on, its your (our) destiny.)

Today, Developer A knows the whereabouts and functionality of the session variable key MSN, he uses it to hold the MSN of the customer, this eventually gets saved into the database. Tomorrow, Developer B creates another session variable key MSN_PP which he uses for the same purpose, except for to hold the MSN of a customer another sales flow.

We need to have a common knowledge base of the meaning of the session variables, but how do we do so in the most efficient and effective manner? (When all the architects have left the project, the design documents way out-dates) The first idea was a Microsoft word document. But, to serve the purpose here, the idea of a knowledge base for session variables must be as good as it is painless and immediate when it comes to looking it up / contributing to it. The solution must not give the developers the inertia to find out what a session variable does or write down what they know about it. Developers would want to have information without leaving the current screen, and most importantly, accurately with each revision of change.

Because not knowing what is available and it is always more convenient to create new throw-away session variable keys (MSN1, MSN_New, msn_9, tissueWipe_1, tissueWipe_2), we’ll never have a clear picture of what might be the session variable primarily responsible for controlling / holding something.

So we introduce to you two key enablers (henceforth forming the solution), these are not shy to us Java developers, SessionAttribute.java / ESessionAttribute and JavaDocs.

SessionAttribute.java

Like the instinct of a good and responsible developer, our first level of responsibility comes from the way we name our session variables, we strive to give short but predictive variable names to our session variables. E.g. msnInUse, msnList, dslId. We provide a brief write up on what we create the session variables to do for its lifetime in the source code, what know exactly what data they should hold, which flows they appear.

On creating …

1. Give session variable names and keys concise and predictive names.

2. Put all the session variables keys in a central class, SessionAttribute.java.

On using …

1. Check if the session variable key is defined in SessionAttribute.java, if it is, use it. If it is not, create a new one in SessionAttribute.java / identify a suitable candidate for re-use.

On refactoring existing …

1. Check the JavaDoc on what it says the session variable is for, if it fits your description of what you need a session variable to do, use it.

(Senior developers could do more in this section by contributing to SessionAttribute.java whenever we come across a session variable we know what it does, as a lot of existing session variables have been created with painful names, e.g. resHm, flrp_fnn_JK1, it is very hard to decipher what it is doing.)

public class SessionAttribute {
  public static final String msnList = "msnlist";
  public static final String businessAddress = "add";
  public static final String residentialAddress = "resHm"; // This is where i want to really say "thanks to SOSSession.java, i do not need a wild guess what resHm" because it was created ages ago.
  public static final String billingAddress = "arbor_add"; // See how easy it has now become to know resHm and arbor_add are actually cousins?
  public static final String statusCheckSessionDO = " statusCheckSessionDO" // A complex object
}

JavaDocs

The above (SessionAttribute.java) would not be complete without a good JavaDoc that we can reference / generate (into HTML ones like the one here http://docs.oracle.com/javase/6/docs/api/). More importantly, we are able to contribute and build towards a technical knowledge base in a way universal to Java programming.

This is amicably the most crucial and important part of being a responsible developer – documentation.

/**
  * Session variable to <Your one liner analysis of the session variable goes here>.
  * <p>
  * If you have more valuable information, it goes onto the second line onwards. The first line above should always be concise.
  * </p>
  * <p>
  * Type: {@link StatusCheckSessionDO } <- Does this session attribute key reference a complex data type or a simple String like “yes” or “no”? indicate here.
  * </p>
  * @since <Since which release?> (e.g. 1 or 5.6b)
  * @author <Your name> (e.g. Chin Boon)
  */
public static final String businessAddress = "add";

* {@link StatusCheckSessionDO }is a JavaDocs syntax that will help you generate the following clickable link to fast forward your search, both in an IDE, and on the JavaDoc HTML output.
ESessionAttribute.java

You have heard of me mentioning ESessionAttribute.java but have not seen it being mentioned throughout the article up until here.

As you know, Java 5 gave birth to a new Java class / construct Enum. Enum needs no further explanation, and a whole lot of tutorial and books cover this.

You are right if you are thinking ESessionAttribute.java is the enum counterpart of the above SessionAttribute.java.

But why didn’t you jump straight into providing an enum based solution instead of a class full of static final constants you ask? The answer is simple, most maintenance projects are still “stuck” in the Java 1.4.2 paradigm and as much as they want to do more with enum, these developers just couldn’t. So if you are a “Java 5 and above” developer, spearhead into ESessionAttribute.java, an enum based counterpart of SessionAttribute.java!

Download source file SessionAttribute.java

Download source file ESessionAttribute.java