Adaptive Software Solutions

A few days back, while reviewing some code I came across what I considered to an over abundance of assumptions in infrastructure code. Such assumptions in infrastructure code can make software buggy and difficult to change. Let me first explain what I mean by infrastructure code. Frameworks always have interactions that we use when we extend their classes. For example if you have used Struts, then the custom action classes we create, use Strut's infrastructure code from the ActionServlet and the Struts RequestDispatcher. These classes call methods which are overriden by our custom classes, thus allowing our code to get called. Even when we do not use such frameworks, there are lots of places where we have hand written infrastructure code in our projects. Typically these are methods in base classes that are invoked as part of a use case. These methods will do a bunch of things that are determined by reading configuration files, decoding the request that invoked them, and perhaps oth

I have always used ANT to create build scripts, and by and large it has served me well. ANT is simple, and it has a wide variety of tasks, which take care of almost all build requirements. Sometime back when I came across a new build tool called GANT , I was curious as to what it would offer that ANT did not. GANT is really Groovy + ANT. For those of you who are not familiar with Groovy, it is a dynamic language which compiles to bytecode and interoperates very well with Java. So GANT uses Groovy as the language to create build scripts. However all ANT tasks have been made available through Groovy's ANTBuilder. So GANT can use ANT under the hoods, but it is not limited to ANT. If we need to write custom stuff for a build script, we can either create our own custom ANT task, or alternatively we can write a Groovy function or class. This along with being able to easily add consitional logic in build scripts is a very useful feature. Also since we use Groovy for creating the build s

The other day I was trying to represent a String in unicode characters. String s = new String ( "\u0041 \u000A" ) ; What I wanted was this "A \n", and instead, what I got was a COMPILE ERROR String literal is not properly closed by a double-quote What the hell! I have represented characters as unicode earlier in my Java code. So what was wrong here. It seems the compiler did not like the unicode newline character I had added. Here's why... The compiler translates unicode characters at the beginning of the compile cycle. Which means the above source first gets converted to String s = new String ( "\u0041 " ) ; before compilation starts. Now it is quite obvious why compilation would fail. Check out section 3.2 on Lexical Translations to understand what exactly happens in the translation phase of lexical analysis. You might also enjoy reading this issue of the Java Specialists newsletter. If you trying to represent newline or carraige return character

A couple of days back I was debugging a failed test case which was testing an XML generated by a Servlet. We were using JDom for generating the XML, and XMLUnit for testing. Testing involved comparing the generated XML with an XML on disk. The test case was failing on a '\n' character in one of the attributes of the generated XML. The XML generated by the Servlet was something like this: <root att="test \n value"> but JDom seemed to be putting some strange characters in place of '\n' Now I had absolutely no idea about this, but the XML specification has something called "XML attribute normalization". Among other things, while adhering to this specification, JDom replaces all '\n' with Look here for more details. The moment I replaced the '\n' in the expected data, the test worked like a charm.

Have you heard of the quirks mode in web browsers? Well I had not until a couple days back when I ran into an issue of a CSS not rendering properly in a web page I was working on. When I made a request for the page and opened Firebug , I could see requests for the CSS files, and I could also see that they were being properly downloaded. In Firebug's CSS view, I could see that all the CSS classes which I was expecting to be applied were showing up. So, what then was the problem. By pure chance I discovered that only elements from the CSS class were being applied. All inherited elements were not being applied. I also discovered by chance that the tag in the webpage caused this behaviour. If I added a DOCTYPE, everything would render perfectly, but if I removed the DOCTYPE, then inherited CSS elements would not get rendered. Now why would that happen? I decided to Google a bit, and found out that browsers have a quirks mode which is triggered by the absense of the DOCTYPE in the htm