Software a Religious Experience...

Software and Religion, not a conventional topic to really blog. And I sure don't want to start any controversies with the same :-). So what brings me to blog on this topic is that I remembered an incident that occured a long time ago while working for one of my former employers. It's so long ago that I might be bordering on exaggeration and hyperbole as I pen the following... I however need to document this rant for memory.

One fine day, a long time ago, in a galaxy that I happen to live in, the system administrator (an extremely nice person, one of the nicest I have met) at my employer stopped by my cube to enlighten me about the fact that after much pondering he finally had the names that they had been searching for the different environments of our different deployment tiers. I eagerly awaited his revelation. Very enthusiastically, he said the names, "Brahma, Vishnu and Shiva". These three names were to represent the development, testing and production boxes respectively.

To those unfamiliar with Hindu mythology, Brahma, Vishnu and Shiva are the supreme gods of the Hindu religion. Brahma is known as the creator, Vishnu the preserver and Shiva the destroyer. It made sense that the development environment was to be known as Brahma, the QA environment as Vishnu but the fact that production was to be named as "Shiva the destroyer" escaped me :-).

Regardless, the point to note was I expressed my displeasure with the names chosen. I cannot claim myself to be a zealot Hindu (I am a Krishna devotee and fan though). However, I do pray and do believe in some superior power who makes everything work so fantastically in harmony. Such a well oiled machine IMO is definitely more than the work of evolution, i.e., my stance on the evolution versus religion debate; "This is too good to be true!" .. Maybe a later blog on Quantum physics, Temporal Physics, Universe expansion theories would be nice.

So where does the displeasure part come in? Well the three deities mentioned have a very prominent foothold in Hindu mythology and religion. Hindu's, pray to these deities constantly. It was great that our deities were also given the honor of having their names included with current day technology. But, the reason why I did not want the different systems named after the deities was, I was concerned that a developer/QA person/Manager might in a bout of frustration say some untoward remark toward the environment that would inadvertently reflect on the deity in concern :-). In other words, I was not comfortable knowing that a time might come where someone would utter words that would not be appropriate and I would need to listen to the same.

I guess, my point was well taken by the system admin and his kindness and religious tolerance prevented him from pursuing his most revolutionary naming convention. I acknowledge his tolerance and am grateful for the same!

Now the above are totally my paranoiac assumptions. The repercussions to the act mentioned might never have occurred. However being in the software industry, I have seem my share of people cursing different environments for one reason or another. I do not know whether I over reacted in this case. Maybe I did. However unapologetically!

I must acknowledge that I am a hypocrite in a way. I have worked on environments titled "Apollo", "Saturn" and even "Venus"..The last one I am least apologetic about ;-). I too might have stated things that might be conceived as religiously/sexually incorrect . I apologize if there is a greek who's sentiments I might have inadvertently hurt :-(. I might have made statements such as "Apollo is down! Venus sucks big time", i.e., statements that might be considered religiously incorrect . Please note that with Celestial bodies we have the same risk right now.

Regretfully, I must state that if tomorrow I was asked to work on an environment titled "Aphrodite" or"Venus", I would not be the first with a protest (sheepish) of the naming convention..:-)

It seems that gods of the past, i.e., those that do not have a following in the current main stream religions do not have advocates defending how their names are used. The gods of the present day, i.e, those with an active religious following do have strong advocates.

Growing up, I remember that my family used to often pay obeisance to a deity prior to starting some critical task, i.e., starting an industry, buying a car, building a home etc. A token of that prayer often found itself itself into the endeavour. For example, we buried a metallic symbol of our deity under the foundation stone of our home when we moved in for luck and to guard us from some untoward incident and bad luck.

Another case in point, during my university days, I was a Teaching Assistant. One course that I taught was Internet technologies such as HTML, Archie, Gopher etc etc...I used to take my students to a sample home page that I created. I was young and during that phase, I had different preferences. My home page had a banner with two flaming skulls decorating the same. Well, the skulls were not well received and one of my students complained to the professor in charge that she believed that I was a "Satanic Worshipper" and took objection to the skulls. My professor immediately ordered me to take down the site. Phew! Do I look Satanic in any way? People please go beyond my features when and if you decide to comment :-)))! Anyway, the point to note is that my actions had hurt someones sentiments.

Being religious as I am, I often wonder, what would be consequences if I had a simple TEXT file along with my software project that wished the project well. In Hinduism, we have prayers that are executed when an auspicious task is to be performed. As a religious software person, if I were to include a text file with prayers for the success of the project, would I be placing myself in bad light? How would it be received?

The atheist would not prefer its presence as they would argue that software is based on pure science without religious connotations. A person from a different religion would potentially not feel comfortable with working on a project that has the blessings of a deity that is not part of their religion? If the language of the well wishes were not based off a particular religion, I guess the latter audience could be appeased.

The software developer and audience therein are a mix. It is a blend of people from multiple religions, races, atheists, agnostics working together to accomplish a common goal. We break barriers such as races, religion and other separations to achieve our goals. We each subtly bring in the richness of our beliefs without imposing the same over our fellow man. These hidden beliefs and strengths cannot be discounted...

In conclusion to this light hearted memory, I would say, like in politics, one needs to be careful regarding where religion and software meet. Tolerance is the word my friends!

Live long and Prosper!

Jupiter Eclipse Plugin for Code Reviews

Recently, I had my code reviewed. My reviewer had some very nice suggestions for change. Also had things in there, I didn't necessarily agree on, but that's a whole different blog :-))

The day's of printing out the code and running through the same in a meeting room is a bit passe! Primarily for security reasons, what if one touches a raw nerve of the guy whose code we are reviewing...with all these mall incidents etc, its too scary..remote handling of the matter that too with day and age of the internet is definitely the preferred and prudent route. I am sure my reviewer would have felt the same seeing my halloween features :-))..I better be kidding here!

My reviewer had painstakingly (thanks again if he ever reads this) interspersed in my code comments for improvement and checked the same into SVN. Eclipse has a TASK's tab that can display items like TODO's or FIXME's etc. Pretty neat. I could then open Eclipse's task tab and run through the individual TODO's and FIXME's and address the review issues.

So I started off addressing his issues. Where do i start? Which is high priority? What should I do after fixing the concern, just delete the comments? Hopefully he will do a "diff" on the source files when he re-reviews :-))))...maybe I can be smart enough to just delete his comments and leave for the day ...lol...kidding of course ..I don't advocate this practice...

Somethings to note about this. There is no PRIORITY associated with the FIXME's so all appear as the same severity. Of course going into each of those FIXME's can provide commented details.

Additionally the review involves the user having to repeat themselves in writing the comments. For example, Coding Style, Optimization etc and specifics there in (no common language). Also the review involves polluting the code base with the comments that later need to be removed after addressing the same; ugh for pain !

Also, in a team environment, it is possible that a checked in code base is reviewed by more than one individual with different comments and potentially different severity. Also, in terms of feedback to the reviewer, there is no easy way of saying what one did to fix the issue or the fact that they won't fix an issue because of some reason or how it was fixed unless maybe listing in an SVN commit or within the code as java doc. Also from a Team perspective, with Task comments, it's not easy to assign specific elements of a review to different people in the team. "You John Doe, get all the FIXME's that contain 'Code ishtyle in the comments'"!. What about duration since a review was posted and the review did not meet a resolution? Maybe this can be addressed by creating a project in your favorite bug tracking tool for the code review? Any thoughts about the pain points there in? "Sanjay pretending to be in deep thought (an anomaly of nature) now, surely there could be an easier way!"

Let me speak a bit in the third person, my son does so all the time, "Yash hungry, Yash going away, Yash Sad, Yash gonna beat u up!"..so emulating him , "Sanjay searching web for something as he is lazy to do something or contribute personally!". "Yay! Sanjay finds something!"

Helping out with all the above but not limited to, is a nice plugin for Eclipse called Jupiter.
Think of Jupiter as a Bug tracking tool for code reviews. Its an Eclipse embedded JIRA of sorts. I tried to use this on a simple project that I created and was rather impressed with what I saw. I could expand with examples of how it works but primarily due to laziness, will allow you to discover its features via the user guide and trying it out :-))) Sheeeeepish and totally shameless here!

As a note , I couldn't get the plugin to work using the update site. The plugin was not picking any of my source files for review..kinda defeated the purpose. Had to manually install the jar I obtained from HERE. After that all was smooth as silk, got em examples woiking...

Don't think I wan't to recommend this to my reviewer, as I definitely don't want a review of a code-review tool...its hard enough finishing the code review ;-))) kidding as always!!!!

If I were leading a team, I would definitely look toward exploring this tool further...

Enjoy!

ThreadDeath and Throwable

I was looking at some code recently and noticed that java.lang.Throwable was being caught around code doing some business processing. Catching Throwable or for that matter catching java.lang.Exception should be done with due consideration. Catching specific exceptions and handling the same should be the preferred route unless there are good cases for catching top level exceptions, which there are.

Anyway, my interest is not really with the above but more on the class java.lang.ThreadDeath. ThreadDeath is a sub-class of java.lang.Error. If one catches, java.lang.Throwable, then there is a possibility of also catching java.lang.ThreadDeath in that code.

The javadocs on ThreadDeath states:

"An instance of ThreadDeath is thrown in the victim thread when the stop method with zero arguments in class Thread is called.
An application should catch instances of this class only if it must clean up after being terminated asynchronously. If ThreadDeath is caught by a method, it is important that it be re thrown so that the thread actually dies.

The top-level error handler does not print out a message if ThreadDeath is never caught.

The class ThreadDeath is specifically a subclass of Error rather than Exception, even though it is a "normal occurrence", because many applications catch all occurrences of Exception and then discard the exception. "

So ThreadDeath can be noticed only if a call to thread.stop() has been made.
The stop() method in Java has been deprecated due to its usage being inherently unsafe.

As per the Java doc recommendation, code that might catch ThreadDeath should propagate the same higher up like shown below:

So for example:

try {
// Do some biz processing
....
} catch (Throwable t) {
if (t instanceof ThreadDeath)) {
throw ((ThreadDeath) t);
}
.......
.......
}

I remember my Architect (a very very smart man) during my earlier days when using jdk1.2.X, jdk1.3.X etc making sure of the above.

Now with stop() being deprecated can we safely assume that no code would ever call stop() on a Thread? I don't think we can be that optimistic as even though deprecated, it could still be invoked. So until the stop method is removed from the JDK, I believe it would be prudent to throw ThreadDeath when catching Throwable or Error specifically for the two reasons mentioned in the javadoc (contrary views I'd love to hear):

"If ThreadDeath is caught by a method, it is important that it be rethrown so that the thread actually dies.
The top-level error handler does not print out a message if ThreadDeath is never caught. "

I wonder if the practice of re-throwing ThreadDeath is still being followed :-) ?
Eric Williams book about the Threads is a nice read. Look for Thread Death in the example.

I cant wait to read Brian Goetz's Java Concurrency in practice, need to buy this book soon...:-). I love async code but it has been rather long since I have played (note the wicked word played :--)) with threads as last few years have all been spent faithfully following j2ee container thread usage recommendations.

Generics and Erasure in Java 5.X+

This blog is primarily as a note to myself in understanding generics. Prior to moving to OSTK, I had very limited understanding of Generics and Java 5.X+ features. Although not an expert by any means, I am comfortable ranting about the same :-). With Java 5.X, Sun introduced the concept of Generics. Generics allow for compile time type-checking and thus a safer code base.

For example,
In 1.4.X of JDK the following would be allowed at compiled time:

List l = new ArrayList();

l.add(new String());
l.add(new Integer(2));

In other words, we could accidentally place an Integer into a List of Strings.
With generics in Java 5.X+ one could alter the above code to:

List<String> l = new ArrayList<String>(); 

l.add(new String());
l.add(new Integer(2)); //--- Compile Time Failure

At compilation time, the above code will fail to compile as the List has been defined to contain only the type of "String" and the line showing addition of an Integer will fail. Nice and safe compile time type checking :-).

Consider an Object Holder that can hold an object of any type defined in Java 1.4.X:

public ObjectHolder {
  private Object object;

  public ObjectHolder(Object object) {
    this.object = object;
  }

  public Object getObject() {
    return object;
  }
}

ObjectHolder stringHolder = new ObjectHolder("Hello world"); 

ObjectHolder integerHolder = new ObjectHolder(new Integer(2));

..What about...the following line:

String string = (String) integerHolder.getObject(); //-----No Compile time warning only Class Cast....run time

With 1.5.X things change for the Better:

public class ObjectHolder<T> {
 private T object;
 public ObjectHolder(T object) {
   this.object = object;
 }

 public T getObject() {
   return object;
 }
}

where T holds the type information and we can also use the above to declare type safe Object holders like:


Code using the Object holder could say:

ObjectHolder<String> stringHolder = new ObjectHolder<String>(new String("Hello World"));

or

ObjectHolder<Integer> integerHolder = new ObjectHolder<Integer>(new Integer(4423));

String string = stringHolder.getObject();

Integer integer = integerHolder.getObject();



Note that there is no casts involved in the above code.

However, what we cannot do is add a method in the Object Holder that does the following (for example, not the best) :

public T createNew() { 

T other = new T();

return other;
}

Why we cannot do the above is due to erasure in Java. What we mean by erasure is that the Type information is lost in the generated byte code or in other words, the generated class files are like 1.4.X classes without Type info.

Why Sun did the same is to support backward compatibility. Backward compatibility is not to be able to run 1.5.X compiled code on a 1.4.X VM but instead to allow 1.4.X VM compiled code to co-exist with 1.5.X compiled classes and run on a 1.5.X Java VM. Running 1.5.X compiled classes on a 1.4.X VM will result in a class version incompatibility error.

The cost of this backward compatibility is that with 1.5 we do not have access to the Type information at run time.

I have a couple of feelings on this. Maybe 1.5 should not have supported backward compatibility and supported Runtime Type generics retention. However, maybe their thought process is that if they they could drop the backward compatibility at version 1.8 and by then all folks must have converted their libraries to be 1.5.X+ generics ready. A definitely good argument. Maybe on the flip side, they should have released a 1.4.X version that had many of the performance and other enhancements (for loop etc) and have 1.5.X version that was not backward compatible. A generics enabling option in the JDK and JRE might have been another option?

Additionally, if one wanted to run 1.5.X compiled code on a 1.4.X VM, there is always Retroweaver to the rescue :-)...thanks to Richard Rodrigues a former colleague of mine, that I know about this tool.

A confession to those reading this post, all the code above has NOT been tried on a compiler, I just wrote it here..so if it has compilation errors, I shameless blame the blogger that they do not have in built java compiler :-)))) as yet!

Some Links:
Neal Gafter's Blog on erasure
Java Forum Discussion on erasure