XSLT engines are not created equal

It's been a while since my last entry. It's not that I am too lazy to write anything; it's just that my daily grind has become so mundane and mind-numbing I hardly ever had any idea for a new entry. Maybe that's a sure sign telling me to start looking for a new job.

Anyway, we are building this diff tool that compares airline schedule files. It's quite sophisticated now from its humble, simple beginnings, but the basic flow is it takes two input files, compares them based on business rules, produces a report object, uses xstream to convert it to XML, and finally uses XSLT to generate an HTML report.

Of course it works perfectly in our development environment; we also tend to stick to small input files. As soon as we shipped it to our customer, we heard the bad news that if you put it against two big input files (15 MB and 4 MB) and run it from the command line, it just sits there forever. When we tried it here, we let it sit there for 10 hours before killing it off.

So yesterday we had a company party to celebrate the cool summer days in Texas (hey, we are not even over 100). After a few margaritas, we sat down to figure out what the problem was. We ran the same two files in IntelliJ, and it worked, even though it took a while. Only on command line it hangs. Looking into the scripts, I noticed that we had weblogic 7.1 jar file in the classpath, which we didn't have in IntelliJ. Thinking maybe the old XSLT engine in weblogic got used instead of the one in the JDK, we commented out the weblogic jar, and kicked it off. After getting another margarita and came back, voila, it worked!

We all know XSLT is Turing Complete, but that doesn't always mean it'll finish its computation in your lifetime.