Code generator, -noun : a tool used by management to regulate (read: reduce pay) or replace the software engineering intelligentsia with code monkies.
Seriously, that was what came to my mind when I first heard the term. In fact, I was right. It turns out the director of the company I was working for at that time, whom introduced the term to me, defined it exactly that way.
Fast forward a few years, I joined a Canadian/German outfit that just off-shored part of their dev team. It was a J2EE and Swing laden sweatshop in the tropics. At least it looked that way during the inquisition, or interview in some nomenclature, with all the J2EE and Swing interrogation. I was in for a big surprise. The first day at work, I was tasked to implement a simple search screen with a link to a dev guide and coding conventions. I was excited, getting down and dirty so quick and early has never happened to me before. I reminded myself to buy the lotto that day. Sadly, that thought didn’t last, as quickly as it faded, it was replaced by apprehension after I read the guide. I quickly did as the dev guide suggested, created my business interface, annotated it, created the implementation and filled out the business logic, run the ant task to build and deploy. Lo and behold, my EJB 2.1 SSB and the official confirmation of my officiation of the office of the code monkey.
Surprisingly though, I stayed and enjoyed working there longer than I first suspected, which was 1 day. The framework, allowed me to write business code without hassling with all the ejb 2 overhead, such as home and remote interface, xml configuration, etc. Plain old java beans became persistable entities (no, not ejb entity beans) as easily. All this was before Java 5, before EJB3. I was even developing swing interfaces without dealing with Swing code most of the time, it was a framework not unlike JSF, years before JSF. I only had to deal with Swing code when there were requirements to build some very non-standard UI behaviours, which is a testament as to why BAs/End users should never be given control over defining User Interfaces.
Interestingly, after my time there, code generation has been a very useful tool to me to solve problems as well as to improve development efficiency. We were using xdoclet back then to do compile time code geneartion, but with advent of annotaions and the mirror API in Java 5 and its standardization into the JDK in 6 and a number of byte code/runtime manipulation libraries nowadays, the potential for compile and runtime code generation is almost limitless.
During the JAOO knowledge sharing session a few weeks back, discussions about TDD came up. Someone remarked about how un-enforceable it is and its up to the developers discipline. That immediately reminded me of some POC annotations I wrote a while back when the mirror API was first made available in jdk 5, along with the processors, that generated skeleton unit tests. If I annotated my business interface or class, at compile time it would generate Test classes and test method for all the public methods in the business interface and class. Of course the test methods were generated to throw an exception with a “TODO” string in it, I still had to write the test code. If we wanted to enforce this, all we have to do is add a checkstyle like mechanism into the source check-in hooks to inspect the business classes/interfaces for that annotation. Obviously, this doesn’t guarantee that the test code is implemented or even correct/useful, but it is one step closer to TDD.
