Clean Code: How important is it ?

January 27, 2011 3 comments

I’m not inspired by many things to write a blog post, but something happened today that gave me the energy to write this post. As noted by the name of the blog, I love groovy. I’m loving Python more and more and even like C#, but I think Groovy is the ultimate for expressive code. I know that’s debatable, but some of Groovy’s benefits(compared to Java) simply are not debatable by reasonable people in my opinion. I recently suggested to some developers on my team to read the book “Clean Code” by Robert Martin. Maybe a week or two later, I sent a link to the Agile Principles @  And I’ve been introducing groovy into our newer projects because I think it allows for coding tasks to be written cleaner and done in fewer lines of codes.

I often find cases where a developer is doing something completely unnecessary in code. Unnecessary especially if you think of the Groovy alternative which is available in the projects I’m referring to.

Let me know know what you think about these cases.

We have a Groovy class with several static methods, like this one, that do basic select, insert, delete, update statements. This project has no ORM because I don’t want the memory overhead.  It executes an update statement and returns the number of rows modified, Groovy takes care of everything else.

Example 1:

        def static insertMessage(String server, String jobName, String jobInstance, String logLevel, String message) {

                def sql = """
                        INSERT INTO LOG_MESSAGE (
                        ) VALUES(
                                ${new Date().toTimestamp()}


A second developer comes along and writes this method in the same groovy class.

Example 2

        public static int updateStatus(Long runInstanceId, Date completedTs, int threwException, int resultCode, String result) {
                Connection conn = null;
                int rowsUpdated = -1;
                try {
                        conn = ConnectionFactory.getConnection(ConnectionFactory.INTERNAL_DATASOURCE_HANDLE);

                        Sql db = new Sql(conn);
                        String sql = """
				update run_instance set completed_ts=$completedTs,
				where run_instance_id=$runInstanceId
                            rowsUpdated = db.executeUpdate(sql);

                finally {
                return rowsUpdated;

So I asked the developer, which would you rather maintain ? They essentially do the exact same thing, but 1 has 2 statements and the other does the same thing  just in many more statements. I sent out the agile manifesto because the principle, “Simplicity–the art of maximizing the amount of work not done–is essential.” is either not known, understood or appreciated.  It’s like writing more code is good, all the time for some developers.   It wasn’t a Groovy or Java question, both were Groovy.  Example 2 in my opinion is less simple and has many unnecessary statements.  Why write unnecessary code ? Which would you rather maintain ?

Here’s a different type of example. This method is called by a service class that is exposed via BlazeDS to a Flex client.

Example 3

        public static List<Contact> getContacts(String jobName) {
                def contacts = []
                def sql = """
                                contact_name contactName,
                                contact_type contactType
                        	job_name = ${jobName}

                db.eachRow(sql) {
                        contacts << new Contact(contactName: it.contactName, contactType: it.contactType);


Another developer comes along and writes this code(Example 4) in a Java class, rather than us than use Groovy. The developer notes that he doesn’t have to write Java Beans,

and this makes it a better option than the above example.  He also notes there is no bean to maintain in ActionScript either.  Also  the SuperDao code that returns the list of maps was written specifically for this project, by said developer.  Even though refactoring becomes painful, he maintains, no bean maintenance is worth it.  What do you think ?

Example 4

        public static List<Map> getInstancesByName(String group, String name) {
                List<Map> list = new ArrayList<Map>();
                String sql = "select * from RUN_INSTANCE where job_group=? and job_name=? order by fire_ts desc";
                try {
                        SuperDao dao = ConnectionFactory.getDao(ConnectionFactory.INTERNAL_DATASOURCE_HANDLE);
                        list = dao.executeQuery(sql, jobGroup, jobName);
                } catch (Exception e) {
                        log.error("SchedulerService.getJobInstancesByJobFullName() failed. message:" + e.getMessage(), e);
                        throw new DaoException(e);
                return list;


Which would you rather maintain, Example 3 or Example 4 ?

Here’s more of the query results as a List of Maps.
Do you find this method clear, and would you prefer to maintain this or would you refactor to this to something else ?

Example 5

	public static final Map getContactListAndSLAByJob(String jobGroup, String jobName) throws SQLException
		AppDao dao= null;
		Map contactsAndSLA=new HashMap();
		try {
			String sql= "select * from contact order by  contact_group, name";
			contactsAndSLA.put("CONTACTS", dao.executeQuery(sql));
			sql= "select * from SLA where job_group=? and job_name=?";
			Map sla_=null;
			List<Map> slaList = dao.executeQuery(sql, jobGroup, jobName);
			if (slaList.size()>0)
				Long slaId = (Long)sla.get("SLA_ID");
				if (slaId!=null)
					sql ="select email from SLA_CONTACT where sla_id = ? and sla_level=? order by email";
					sla.put("WARN_CONTACTS", dao.executeQuery(sql, slaId,"WARN"));
					sla.put("ERROR_CONTACTS", dao.executeQuery(sql, slaId,"ERROR"));


		finally {

		LOGGER.debug("SLA and contacts = "+contactsAndSLA);
		return contactsAndSLA;

Last one, what do you think of this ?

   public void methoCall() {
                JobExecutionResult result = null;
                int isExceptionBol = OracleBoolean.FALSE;
                int resultCode = JobExecutionResult.ERROR;

A single variable name is small issue, but it’s not when you put it in a huge method or follow a bad naming convention whenever you have this type of variable.  So I asked a developer about this since we got on the topic  of code clarity.   Look at variable name “isExceptionalBol”. First off, wouldn’t you think this would be a Boolean given the name ? Secondly, isn’t having this variable name prefixed with “is” and end with “Bol” redundant, and lastly isn’t it just a bad variable name ? I mean do you know what this variable might be storing, i mean what exactly is true or false, or int ? The author of this fragment went on to say, variable names don’t matter if the code works. This is from one of our senior most java developers.  Obviously, I don’t agree with that statement,what about you ?

Categories: Groovy

I think I figured out why good Java developers are so hard to find

October 14, 2010 45 comments

Let me start by saying I have an open java position that has been open for about 3 months now.

The problem has everything to do with what you do in your free time. Let’s say a family member asked you to create a website that had some dynamic content, but they only had a $10/mo budget for hosting. What do you do ? Let me tell you what most guys don’t do: chose java. Let’s say you wanted to teach yourself programming, what might have motivated you to take this on: a video game, a phone app, a website, a facebook app ? Take your pick, and when you decide to take the plunge what are the chances that you’ll end up choosing java? Slim, at best. Android, would be the only thing that could pull you to Java given those very likely choices.

If you’re already a good programmer, you probably program in your free time. If nothing more than dabbling or trying new stuff out, you probably spend time doing programming related stuff on your free time. This “dabbling” is probably how you managed to learn ”tool X” and you eventually ended up using ”tool X” at work or answering questions about it in an interview. My own experience goes something like, when I was a C++ developer, I taught myself VB and got a job as a VB developer. When I was a VB developer, I taught myself ASP and got a job as a ASP developer. When I was an ASP developer I taught myself Java and got a job as a Java developer and so on. I don’t think my evolution as a developer is unique at all. I suspect, this is how most programmers manage to keep themselves employed.

I’ve been looking for a junior java developer with about 3 years of experience who knows java and sql. That’s it. We’ve interviewed a little over 10 people. Here’s what is extremely obvious about the candidates I’ve seen: none of them do java development of any kind on their free time. Whenever anyone of them mentioned anything they’ve done on their own, it almost always was a website and almost always involved PHP. When as I evolving as a developer, Java was an attractive language so much so that I spent my free time learning it and developing applications in it – just because.

My theory goes like this: Good java developers are hard to find because fewer and fewer of them are being created. New developers are not choosing java to “cut their teeth” on. And I suspect that coming from whatever they are coming from, java doesn’t look appealing. Those after-hours projects that really give you that “learned the hard way” experience seems to be happening less in the Java world. When you take my original scenario, where you have to create a simple app and host it inexpensively; what do you think an inexperienced person will chose when they stumble on the Google App Engine and realize they can host their app for free: Java or Python ?

Categories: Uncategorized

What I learned from the Play! framework

May 17, 2010 1 comment

I like the Play! Framework and

After reading a post by the author of the framework (, I know that I’m in good company with regard to thinking the servlet API is a major problem for java web applications.

He’s simply not a fan of the servlet API, I am. I think the implementations are the problem.  I  agree that one of the major problems is how it handles state.

EasyGSP deals with the servlet API in a less radical way than Play! There is an Application(or Context), Session, Request and Response object in EasyGSP. There are no servlets, listeners or filters. I thought it very important to have those familiar objects for a couple of reasons. The first is because there are some libraries that depend on the servlet API, like file upload libraries. The second reason, is because anyone coming from java web development would expect there to be a app, session, response and request object.

The last release did something I was quite pleased with. It allows you to stand up 2 or more EasyGSP instances and via JGroups the instances stay in sync. The part I was so pleased with was that the developer didn’t have to make objects Serializable or worry about SerialVersionUIDs. A couple of small changes to the Groovy jar made this possible. I thought all of this was pretty sexy, but I’ve since concluded that it may have been unnecessary. Unnecessary because mostly what is sent in a cluster is session state. If a SerialVersionUID is not in a class the jvm will add one, but it will be different on each server.  Keep in mind EasyGSP works with scripts, not precompiled class files.   Basically, the last release took care of all of the serialization details for you. You didn’t have to mark classes as Serializable or anything else.   Now if I simply had not allowed certian objects to be in session state, I wouldn’t have to add those features.

Another feature in the previous release was the ability to monitor files and reload the classloader based on what changed. I was pleased with this too, but I knew this was a potential problem because tossing classloading is expensive with regard to memory. Nevertheless, this feature allowed you to change anything, in any file and your changes would be reflected on your next page refresh instantly, with no manual server restarts. I think your Grails and Tapestry both work in a similar fashion. When there’s a certain kind of change, they save the session to disk, create a new classloader, reload the session state from disk. This works well enough for development purposes, but it’s one of the reason you run out of memory when using certain frameworks. After all of that, I’ve realized that this too was kind of  unnecessary.

Play! and other non-java frameworks are very picky about what they allow you to persist in state. With regard to the servlet api, when a class is loaded and persisted to session scope and that class is later changed and reloaded, you can have a situation where if you instantiate a new version of that class, it will be different than the one that is already loaded in session scope. This is one of the problems JRebel solves. Tossing classloaders solves it too, but it’s not a good solution. I had just put this problem on the back burner, went with tossing classloaders and thought that I would eventually make EasyGSP work with JRebel or LiveRebel at some point in the future.

I’m more concerned with class reloading than statelessness but after reading Bort’s article,  I decided to take a  similar approach and simply change EasyGSP so that only the “toString()” value of any object is allowed in Session and App scope…I’m convinced that what you gain is worth more than what you lose.   If more servlet API implementations worked this way, the JRebel guys might not be in business. That might be a overstating things, but while I don’t agree with everything in Bort’s articles, I do agree that Play’s approach does indeed solve a few problems. It’s not a perfect solution, but short of JRebel its the best approach to deal with class-reloading.

No longer do I have to toss classloaders and since there are no classes other than String hanging out in state, I don’t have any out of sync classes.  It should be noted that Servlet API implementations don’t  force you to store everything  in session state.  You could simply not do it. I get that. But in a shared, hosting like enviroment, hoping people will do the right thing is not an option. That’s why you can’t do certain things in the Google App Engine. The environment must be controlled. Previously, I blogged that Groovy’s class reloading wasn’t enough, it is. I’ve been working with this change in place for about 2 weeks now, and all of my changes are reflected instantly just using Groovy’s default class reloading features. It’s beautiful.

Categories: Groovy

ThreadPool vs Thread-per-Request

May 17, 2010 4 comments

I’ve just started  doing some load testing on EasyGSP and found the first round of results a little surprising.   Pooling and reusing resources is a common practice in application servers.  Thread pools and connection pools are 2 such examples.  Given that this is such a common practice I’ll accept that more testing may be required. With that, it should be obvious that you’re about to read that the “thread pool” performed worse than the “thread per request” version.  It performed worse in just about every measure.   I’m using the ThreadPoolExecutor class for the thread pool.  It’s in the jdk so it has to be good I figured.  Maybe it is, but I’m not there yet.

The way I tested this was rather straight forward.  I compiled the “per request” version, started the server, ran the test in JMeter, opened visual vm and recorded the memory consuption.  Then I recompiled the same code with the thread pool in place, and repeated all the other steps.

The first request for each page requires the code to be compiled and cached.  You can see the effect of this in the “Max” column.  Overall the the page performance is acceptable and I was able to get the thread pool performance to virtually match the “thread per” version by changing the initial queue capacity .  The call looks something

executorService = new ThreadPoolExecutor(poolSize, maxPoolSize, keepAliveTime, TimeUnit.SECONDS, queue)

but the JVM memory comsuption was always more and that’s what I was most interested in.  Since EasyGSP’s goal is to host many applications on one jvm instance the smaller the memory foot print the better.

You can read what Sun has to say about ThreadPools and this class here:

The part about improved performance is questionable.  So for now,  “thread per request” it is.

Thread Pool Results

No Thread Pool Results

Categories: Groovy

Latest EasyGSP Release

April 29, 2010 1 comment

The latest release of EasyGSP, 0.4, adds the following features:

  • Failover/Loadbalancing clustering
  • Template Inheritance
  • Better class reloading
  • Implicit method for sending email, and for formatting Dates
  • Flash Scope

This feature is a necessity for uninterrupted service. JVM restarts will definitely be required, and this feature should allow such restarts to happen without an interruption to service. State transfer is handled via serialization. To accommodate this without any effort on the developer’s part, (ie marking objects as Serializable and declaring SerialVersionUID in those objects), the groovy 1.7 jar included in this distro, has been recompiled so that all GroovyObjects are Serializable.  In addition, the SerialVersionUID is added via ASM outside of the groovy jar. So objects are serialized and passed between servers, but the developer doesn’t have to deal with the details.  The code for with Serializable and SerialVersionUID just didn’t look or feel very “groovy” in EasyGSP scripts, so I did away with it.

Template Inheritance
EasyGSP’s template inheritance syntax looks much like Django’s and/or Smarty’s implementations.

<%@ extends ‘parentTemplate.gspx’ %>

<%@ block main %>
My content
<%@ endblock %>

Some work remains to be done on producing better exceptions but otherwise it’s working ok.

Class Reloading
Groovy class reloading works, but it’s limited in what it can do. I mean, it doesn’t solve the class reloading problem say like JRebel does. Now, if certain classes are changed the class loader is tossed and a new one is created. JNotify is used to monitor the file changes, and its works pretty well.  That is, it works the way most class reloading works, the session is persisted, a new class loader is created and then the session is restored. Restarts during development are essentially eliminated.

It’s a given that you’ll eventually need to send an email from your webapp, so an implicit method was added to allow this. The syntax is this:

sendEmail(Map properties)

so a call might could look like this:

sendEmail([to:’’, from: ‘’, subject: ‘easygsp question for you’, body:’does easygsp support HTML emails ?’])

All of the emails are sent as multipart messages, you can specify an HTML body and attachments. See website documentation for details. Each app can specify its own email server host/port/user credentials. When none are specified, the server’s default values are used.

Categories: Groovy


February 25, 2010 2 comments

In EasyGSP there are 2 styles in which you can code an application, MVC or template(ie straight PHP/JSP/ASP style).

Wait, just in case you don’t know about EasyGSP, you can read about it here:

There are benefits to both, but your background will probably dictate which one you’ll use. If you’re a java developer you’ll probably want to stay with the MVC style that you’re used to. However, maximum productivity(at all cost) may be more consistently achieved using GSP templates only. The reason it’s potentially faster is because the architecture is more simple and templates are independent scripts that essentially have no residual. When you do MVC style coding you’re likely to create more classes and these classes and their instances will be floating around in memory, and referred to by other classes. Then we you change a class, or do something trickier, like change the signature on a static method, or remove a static property, the classloader will need to do some gymnastics and probably can’t and will have to reload all your classes(aka application restart) and you’re waiting for this to happen. Even with that warning, I know anyone that attempts to use EasyGSP will very likely say – ok so how do I make my controller, model and view. So let’s look at that.

A controller in EasyGSP is a groovy script. And if you’re a java developer without groovy experience this is wild and crazy stuff. A groovy script is just some code in a file and it runs from top to bottom. You don’t have to declare classes or methods. I know, this is so free form that it’s a potential noose, but it must be noted that EasyGSP is not a framework. For better or worse, I’m taking the approach to dictate as little as possible in terms of conventions required to get something to work.  Let’s create a simple controller. It’ll accept an upload and save it disk.

Controller – upload.groovy

import org.apache.commons.fileupload.FileItem
import java.text.SimpleDateFormat

def uploadLocation = ''
def uploadSuccessful = false

// if there are no uploads, the map is empty
request.uploads.each { // uploads is a map
	FileItem fileItem= it.value
	File uploadedFile = new File(application.appPath + File.separator +
	fileItem.write(uploadedFile); // save file to disk
	uploadSuccessful = true
	bind 'fileName',
	def sdf = new SimpleDateFormat('MMMM dd, yyyy HH:mm')
	bind 'timeStamp', sdf.format(new Date())
	// when the script is done, control is automatically forwarded to the view

bind 'uploadSuccessful', uploadSuccessful

View – upload.gspx

 <title>File Upload Example</title>

 <% if (!uploadSuccessul){ %>
<form action="fileupload.gspx" method="POST" enctype="multipart/form-data">
 File: <input type="file" name="file"/><br/>
 <input type="submit"/>

<% } else { %>
 Your file was successfully uploaded at ${timeStamp}. <a href="${fileName}">Click here to view it.</a>
 <% } %>


This is pretty straight forward, and something that every developer and framework has to deal with: a simple file upload. EasyGSP knows to invoke a controller by way of the file extension(.gspx). Template request have the .gsp extension. In this example, the controller and view are in the same folder. This is typical, and when the forward() method is explicitly called, control will automatically be forwarded to a template of the same name (minus the extension). It’s assumed that the controller and view are in the same directory, but you can explicitly forward control to any template or controller at any location in the app. Note the controller is in fact a groovy script. EasyGSP checks the content type of the post, and it’s an upload it parses it and makes the upload items available in a map named “uploads”. The map is available via the request object as a method named “getUploads()”. The controller, loops through all of the uploads and writes them to disk. Lastly, the controllers binds some variables (time, filename and status) and control is forwarded to the view.

Don’t get caught up with the bind method. I could have stored these variables as request.attributes, but I would have to access them as request.nameOfAttribute. Using the bind method and request.scope in EasyGSP are equivalent levels of scope. They have the same lifespan. But I tend to use bind because I can use the bound variables in templates without prefixing them with “request”.

There you have it. A simple script based controller that processes a file upload and forwards to a GSP template. Any Questions ?

This and other inglorious examples are available in the EasyGSP download and online at

Categories: Groovy

EasyGSP Explained

January 26, 2010 1 comment

First let me say that things have been progressing nicely with the EasyGSP project.  The most recent releasev(v0.30) fixes several bugs, moves to Groovy 1.7 and benefits from the improved class dependency detection. This means that when class B depends on class A, a change is class A will force a recompilation in class B. This has always worked, but it works better now.  Another plus I’ve notice with the move to Groovy 1.7 is the improvement in error messages generated by groovy. When a property or object is not found it, the compiler makes suggestions.  The error messages are still not great, but java developers are used to long stack traces and should be able to make sense of them.

The web site ( tries to explain the project, but let me attempt to do again it with more context.  I started out as C++ developer, but back in ’97 ASP was becoming hot, and I went from C++ to ASP development. ASP was the first web scripting language I had used professionally and if nothing else, despite its many short comings, coding in ASP was incredibly productive.  Coupled with custom built ActiveX COM objects it was a fairly powerful combo and it as ridiculously easy to use and understand.  While I grew to really like ASP, my preference was always for the C/C++ syntax.  I actually did all of my ASP development in JavaScript.  During this time, I’d toyed around with java and when JSPs starting gaining traction I jumped shipped, because it seemed to have even more potential than the ASP/ActiveX combo.  As soon as I started my JSP and applet development, hosting became an immediate problem.  It simply was unable or very expensive.  Dedicated servers were simply way too expensive back then.  So I essentially had to go back to ASP and PHP for internet hosted apps and Java for anything on the 9 to 5. For a period, I used my home account with TZO to host my Java apps.  As ASP started to show it’s age, PHP gained momentum and Java on the web (outside of the enterprise) stagnated.   Not until very recently has java become a real option for the hobbyist developer.  For about $10/mo you can get a fairly limited, non-shared, java hosting account or an entire OS for the same price at EnjoyVPS.  The point is that there was a span of about 6-7 years (maybe longer) where developing an application for the internet in java was just not an economically smart choice compared to the hosting cost of a classic ASP, PHP or application.  For the past few years, I’ve simply paid for a dedicated server to host my java apps.

Fast forward to Groovy, and it became apparent to me that groovy could be used to fill this void that Sun and servlet container developers never filled in.  Java developers have never had a real alternative to what PHP and ASP developers have had.  Personally, I like JSPs. But JSP development simply feels different than ASP, PHP and now Ruby and Python web development, in a less productive way.  EasyGSP simply tries to fill a void that has never been filled in the Java ecosystem: A shared hosting environment for the JVM, with support for a dynamic scripting language.  I would say “shared” is the most important part of that description.  Shared is important because that’s what will make it cost competitive with the likes of other hosting options.  Everybody knows shared Tomcat hosting sucks.  Who’s used GoDaddy’s Tomcat shared hosting?  When I did, they restarted the server every night at 2am. It was essentially useless.

When I’ve described the project to co-workers they often say why do I need this or worse, they say something like “yeah, I get it and you can use spring or hibernate to do a or b”.  To me, these kinds of responses suggest that they have not had the java hosting troubles I’ve had.  The temptation to use Spring and Hibernate is strong, but it must be noted that those products are memory hungry and not the best choices for a “shared” environment.  Instead of reinventing the wheel, I’ve decided to try and follow the example set by other successful environments.  Whether it be the GAE, ASP, PHP, Ruby or Python, no hosting company gives you full control in their shared environment.  If you have a PHP account, you can’t add a new apache mod because you need it nor can you add or register a new ActiveX dll or .net component to the GAC in an IIS environment when using a shared account.  Similarly in EasyGSP a developer can’t add jars willy nilly to a shared instance.  Let me explain.  But first I should step back a few steps talk more about EasyGSP’s primary objective.

The EasyGSP project has a single objective, that if meet, will determine if the project is successful or not.  The objective is this:  A single EasyGSP instance should be able to reliably host at least 100 shared accounts on modest hardware. I’ve read that PHP hosting companies can put hundreds of PHP accounts on a single server.  Based on what I pay for my dedicated server, if you could get 100 EasyGSP accounts on 1 server that would be enough to make standing up a server worth considering. This project is about creating a cheap hosting alternative for Java/Groovy developers.  If a EasyGSP instance can’t host enough accounts to make standing up a server profitable or cost neutral, then there really isn’t much of a future for a  project like this.  Because if you really want to do Groovy web development without Grails you could do it free on the GAE using GroovyTemplateServlet, Groovlets and Gaelyk but the down side is you’re tied forever to the GAE for some this is unattractive.  In order for someone to decide to standup a EasyGSP server and offer hosting, they will have to be able to make money doing it.  This should clarify the control issue mentioned before. The EasyGSP environment has to be controlled, libraries known to be resource hogs will very likely have to be avoided no matter how useful that may be.  Currently, when you develop an app for EasyGSP, your application contains groovy, gsp and/or gspx pages only. Just like a PHP app is just a bunch of PHP files, a EasyGSP app is just groovy scripts, and gsp templates. No jars. This may seem restrictive to java developers, but it really isn’t. Other environments manage just fine with the same restriction.  It should be noted that any java library can be added to EasyGSP, just not at the application level. EasyGSP has a server level lib folder just like Tomcat, but it does not offer application level lib folders.  Why? Again, this has to be controlled to manage the environment.  Yes, I know someone could take the entire hibernate library convert it and all of its dependencies to groovy files and upload it, but I’m counting on this not happening.

In order for EasyGSP to be truly reliable, some form of clustering will be required.  The latest release includes clustering support but it’s not there yet.  After the edges are smooth out,  the app will be ready for some performance testing.  This testing will measure if EasyGSP can meet its objective: 100 accounts on a single instance.    The test will include a consistent series of file changes and app restarts (not server) to mimic a real hosting environment. It’ll be interesting to see what the memory consumption will be like and how well it can be reclaimed.  On my personal laptop I run EasyGSP as a service and often go days without restarting. Memory consumption for a single instance for a single application is considerable less than a comparable Tomcat hosted app, but that’s expected since EasyGSP is a much simpler product.

There you have it, a little past, present and future.

My next post will be shorter and will include some code.

Categories: Groovy