Reading the Dictionary Is Fun

While waiting for my lunch to cook today, I picked up my son’s Oxford Desk Dictionary to look up a word. I had the word “fop” in my head, and I wanted to make certain that I was correct in what I thought it meant. I was correct that it means a dandy, or an “affectedly elegant or fashionable man.” But that’s not where the fun came in. I happened to flip a few more pages, and I ended up learning two new words: funambulist and funicular.

The first, funambulist (fyu-NAM-byu-list), is another words for tightrope walker. The Oxford dictionary didn’t give any etymological info, but the American Heritage dictionary said it comes from Latin. fūnis, which means “rope,” and ambulāre, which means “to walk.” This word kind of reminds me of “pugilist” which is an old word for a boxer, and pugilism, which is another word for boxing. While you do still occasionally hear pugilist or pugilism, I’ve never heard a tightrope walker referred to as a funambulist.

The second word, funicular (fyu-NIC-yu-ler), means “(of a railway, esp. on a mountainside) operating by cable with ascending and descending cars counterbalanced.” I would never have guessed that’s what it meant if I had just seen it written somewhere. It sounds like something related to a funeral, to me. Now that I know what it means, I can describe the cable cars running to the top of Stone Mountain as a funicular cable car system. Neat, huh?

Will I ever use either of these words in normal conversation or writing? Probably not, but I don’t believe that learning is ever a wasted endeavor. Of course, if I ever get on Jeopardy!, they might come in handy.

 

Greek and Spanish Simultaneously: Is It Possible?

Around April in 2006, I started learning Greek, because I wanted to be able to read the source materials of the New Testament (notice I didn’t say the “original” Greek). I worked on this pretty steadily until late 2007. At that point, I put Greek on hold in order to study Spanish with my son. I have continued to take my Greek bibles to church, but my skills have already begun to fade. I’m having to look up way too many things as I read, which makes it less than fun.

So, I need to go back and refresh the Greek, but I don’t want to abandon the Spanish. I’ve made really good progress in Spanish, and I’d hate to lose that progress. What I’m wondering, then, is if it’s possible for me to study both Greek and Spanish, at the same time? I think I can do it. I already spend around an hour at my computer every morning before I start work, so I could easily replace part of that time with Greek practice. I could then work on my Spanish in the afternoon, and in the car (I’m a subscriber to Coffee Break Spanish). Has anyone else attempted to learn two languages at the same time? Do seminary students learn Greek and Hebrew at the same time, or do they learn them sequentially?

I’m going to give it a go.

Wish me luck.

Dear Apple: Some Java Love, Please?

I love your machines. Truly, I do. Back in 1988 I bought a toaster-model Mac SE, with one megabyte of RAM, and I loved it. It only had a nine inch, black-and-white screen, and I loved it. For various reasons, I sort of lost the love for a while, until 2006. I acquired an iBook G4 in a hardware trade with a friend and I quickly became hooked on the sweet goodness that is OSX. That was in August, 2006. Two months later I bought a Mac Pro, which I love so much I sometimes feel the need to kiss it goodnight.

But there’s one thing about the Mac that bothers me: lousy Java support. Sun handles JDK releases for Windows and Sun machines and every Linux system on the planet. Yet, for some inscrutable reason, you have decided to handle Java for OSX yourself. And, not to be rude, but I just have to say that you suck at maintaining Java for the Mac!!! Let me ‘splain.

Sun released the first version of Java 6 for Windows, Linux and Solaris in December 2006. Two days ago, Sun released the tenth update for Java 6, again for Windows, Linux and Solaris. On September 24, 2008, you guys released Java 6_07, which was nice to finally get it, but it’s only for Leopard systems and it’s only for 64bit machines. My Mac Pro is 64bit and Leopard, but my iBook is 32bit and can’t run Leopard. And what about the tons of other developers out there who don’t meet these requirements? I can’t think of a good reason you have restricted Java 6 in this way, but I can think of a few bad reasons. Probably the easiest to come up with is that you’re trying to force Java developers to buy more expensive Apple machines.

What’s really funny about the crappy state of Java on the Mac is comments from Sir Steve himself, several years ago. I was at JavaOne in 2000. Sir Steve was the Mystery Date™ for the keynote speech on Day One of the conference. His Steveness trots on stage, clad all in black, and proclaims that he was going to make the Mac the ultimate platform for Java developers. Apple would be bundling Java 2 SE with OSX. And the crowd went wild. And he did make the Mac a great Java development platform. For a while. I can’t tell you how many conferences I went to after that, Java conferences, where the majority of developers were toting Mac laptops around. 

But then you started falling behind with the releases. And then you started restricting which of your users were worthy of getting updates. What gives, Apple? If Sun can release timely versions of Java that run on a ton of disparate systems, why can’t you release timely versions that run across your own hardware family? It’s absurd that you are only supporting 64bit Leopard system for the latest versions of Java, and even then you make us wait forever. 

So, how can we fix this? I think you should go back to Sun and say something like,

I’m sorry, Sun. We like to meticulously control everything, but in this case, that desire has caused us to hose down our customers. They’re not happy, and we can’t figure out a good way to appease them. Please, Sun, would you take over maintenance of the JDK/JRE for OSX? We’d really appreciate it.

Or something like that. Something needs to happen soon. Although the lastest version sounds like just another update to Java6, there are actually lots of new features that are going to really improve Java. Except those of us on the Mac have to wait for some unknown amount of time before you guys release your own version. And if we’re not 64bit Leopard, we’re screwed.

Please, Apple, help us out with some timely Java love, OK?

Sincerely,

Joey Gibson

Groovy Sql Closure Examples

My [cref why-i-love-closures post about closures] last week generated quite a bit of traffic and comments, both positive and negative. I decided to followup on that post with a few examples of how to add a method that I believe is missing from Groovy’s Sql class that will execute a closure, and will guarantee that the connection gets closed, no matter the outcome of the closure’s contents.

I’m going to discuss three ways to add a method that does what we want:

  1. Wrap the existing class
  2. Modify the MetaClass of the existing class
  3. Use a Category

All three of these are extremely simple. I think it mostly comes down to preference as to which one you might want to use. Before we get started, let me say that Groovy is optionally-typed. What this means is that you don’t have to declare variable types if you don’t want to. I like not having to declare variable types, so I have not done so in any of these example. You might hate that, and think it sloppy/heretical/evil. If so, and you choose to use any of the code I present, feel free to declare your variable types. So, with that out of the way, let’s start with the wrapping approach.

Wrap the existing class

First, we’ll create a class called ISql that wraps an instance of Sql.

import groovy.sql.Sql

public class ISql
{
   public static newInstance(url, user, pass, driver, closure)
   {
     def con

     try
     {
       con = Sql.newInstance(url, user, pass, driver)

       if (closure)
       {
         closure.call(con)
       }
     }
     finally
     {
       con.close()
     }
   }
}

You can see that we’ve got a class with a single static method called newInstance, to mimic the standard way of creating a Sql instance. It takes the same four arguments that the Sql class does, but it takes one extra argument: a Closure. All this method does is create an instance of Sql, executes the closure, passing in the Sql instance, and then ensures that the connection gets closed, through the call to con.close() in the finally block. To use this class, you can do this

ISql.newInstance(url, user, pass, driver) {con ->
  con.eachRow("select * from Foo") {row ->
    println "ID: $row.id"
  }
}

In this test, we call our special newInstance method, passing in the connection parameters, and then tacking on a closure at the end. Inside the closure, we get access to the connection through the con variable, and then we can do anything we would normally do with a Sql connection. In this case, we execute a query and print the value of each row’s Id column. Nothing too exciting, but it works. No matter what happens inside those closures, the connection is guaranteed to be closed at the end. 

Modify the MetaClass of the existing class

The second way to do this is to add a method to Groovy’s built-in Sql class by modifying its MetaClass. Here’s the code to do that:

Sql.metaClass.static.newInstance << {url, user, pass, driver, closure ->
  def con

  try
  {
    con = Sql.newInstance(url, user, pass, driver)

    if (closure)
    {
      closure.call(con)
    }
  }
  finally
  {
    con.close()
  }
}

Everything after line three is exactly like what we did in the wrapping approach. The magic occurs in line one. In that line, we get the Sql class’ MetaClass, and then grab the static property of the MetaClass. We then add another method called newInstance by using the << operator to append a closure taking the right number of arguments. To call it, we have code that looks almost identical to our last example, but instead of using the ISql class, we’re using Groovy’s built-in Sql class with our special method included.

Sql.newInstance(url, user, pass, driver) {con -&gt;
  con.eachRow(&quot;select * from Foo&quot;) {row -&gt;
    println &quot;ID: $row.id&quot;
  }
}

You can see that with the exception of the missing ‘I’, the code is exactly the same.

Use a Category

Groovy also provides something called Categories that allow you to add methods to existing classes, but they are only usable while the Category is in use. It’s somewhat confusing, and is my least favorite approach, but here’s how it works. You create a class with a static method taking the arguments you want to pass, plus an extra argument, usually called “self”, that will get passed the thing on which you’re calling this method. This special required argument must be the first in the list. Here’s our category called SqlHelper

import groovy.sql.Sql

public class SqlHelper
{
  def static newInstance(self, url, user, pass, driver, closure)
  {
    def con

    try
    {
      con = Sql.newInstance(url, user, pass, driver)

      if (closure)
      {
        closure.call(con)
      }
    }
    finally
    {
      con.close()
    }     
  }
}

Notice that the first parameter to newInstance is that special “self” variable. If you don’t include that argument in the method declaration, calling the method won’t work. I should add that you don’t actually pass any argument for “self” yourself when calling the method. This is handled by Groovy, in much the same way Python programs stuff values into a method’s “self” argument. So, to use the category, you have to wrap your operation in a “use” block

use(SqlHelper)
{
  Sql.newInstance(url, user, pass, driver) {con -&gt;
    con.eachRow(&quot;select * from Foo&quot;) {row -&gt;
      println &quot;ID: $row.id&quot;
    }
  }
}

Here, we declare that we want to use SqlHelper by using a “use” block that contains the category in parentheses. Within the curly brackets of the use (also a closure), Groovy will see our call to newInstance on the Sql class, and will figure out that we want to use the one in the category. It will then call that method, passing the Sql class as the self parameter, and all our other arguments as you would expect. With the exception of having to use the “use” block, this code looks just like the second example.

When Something Goes Wrong

I said that in each case, no matter what happens in the closure, the connection was guaranteed to get closed. Someone commented on the last post that he was concerned that the use of closures would somehow obscure where the problem occurred. It doesn’t. You still get the line number of where things went pear-shaped. For example,

try
{
  ISql.newInstance(url, user, pass, driver) {con -&gt;
    con.eachRow(&quot;select * from boingo&quot;) {row -&gt;
      println &quot;ID: $row.id&quot;
    }
  }
}
catch (Exception e)
{
  e.printStackTrace()
}

In this case, there is no table called “boingo,” and so when I execute this code I get an exception thrown, and from the stack trace, I can see where the problem occurred:

java.sql.SQLException: Invalid object name 'boingo'.
  ...
  at groovy.sql.Sql.eachRow(Sql.java:559)
  at groovy.sql.Sql.eachRow(Sql.java:541)
  ...
  at ISqlTest$_testBadness_closure2.doCall(ISqlTest.groovy:38)

I cut some of the stack dump out for brevity, but you can see that it was a java.sql.SQLException that was thrown, and it references line 38 in the code. That just as much information as you’d get from straight Java in this case, so you should be able to diagnose the problem.

Other Approaches

I should add that you should be able to subclass the Sql class, adding a static method called newInstance that accepts a closure in addition to the four connection arguments. I tried that, but it didn’t work. Actually, it partially worked. The newInstance method I added worked like a champ, but the original newInstance method was no longer visible. I don’t know why, but that’s the behavior I was seeing. It might just be that I’m not familiar enough with Groovy, but I couldn’t get it to work. If anyone knows why, let me know.

To Sum Up

So, those are three ways to add a closure-with-guaranteed-connection-closing method to Groovy. Which of these approaches should you use? Personally, I prefer the second way, adding a method to Sql through its metaclass, but it really comes down to preference. Whichever way you choose should be documented so your teammates understand what’s going on.

I hope that someone on the Groovy team will realize that they left this functionality out of the previous versions and decide to add it for a future version. It really strikes me as odd that this is not in there already, since it seems to fit so well with the language. The fact that various methods inside the Sql class take closures, but not the construction method, makes me think it was just an oversight.

An Asteroid’s A-Comin’

At the bowling alley tonight, after discussing the stock market for a while, my friend says to me, “Did you hear about the asteroid that’s supposed to hit us tomorrow?” I thought he was kidding. So I whipped out my shiny iPhone and checked to see what Google could tell me about this. To my surprise, it told me quite a bit. According to this story from the National Geographic Society,

A boulder-size asteroid discovered just a few hours ago will become a bright fireball when it enters Earth’s atmosphere at about 10:46 eastern time tonight, astronomers announced.

Holy carp! I added the boldface over the really important bits. Let’s read it together, shall we? A boulder-size asteroid, discovered just a few hours ago… That’s really unsettling. I thought we had satellites whose sole purpose was to watch for these things. Oh well, at least it’s a small one that will most likely burn up in the atmosphere. The article did go on to say

“If the object was ten times the size [as the one detected today], we would have picked it up several days in advance,” Spahr said.

“Then we could say, OK, you guys in Africa, pick up and move 50 miles [80 kilometers].”

And people think astronomers have no sense of humor.

Why I Love Closures

I’ve been a big fan of closures for years. I was first introduced to them in Smalltalk, where they were just called blocks. Ruby has them and also calls them blocks. Java does not have them, though there are proposals (such as this one) to add them to a future version of the language. Groovy has them now, and while they aren’t as shiny as those in Ruby, they do work.

So what’s so great about closures anyway? They are blocks of code that retain links to things that were in scope when they were created, but they also have access to things that are in scope when they execute. They can be passed around, usually to methods that will execute them at a later time, in a possibly different context. That doesn’t sound all that exciting, but what is exciting is when the language in question lets you pass in a closure to do some work, and then cleans up after you when the work is done. Here’s an example of some Ruby code that I have written in tons of scripts.

count = 0

DBI.connect(*CREDENTIALS) do |con|
  File.open(&quot;results.txt&quot;, &quot;w&quot;) do |file|
    con.select_all(sql) do |row|
      file.puts &quot;... interesting data from the query ...&quot;
      count += 1
    end
  end
end

puts &quot;Total records: #{count}&quot;

What that code does is declare a variable, count, that will be used to keep track of how many records we processed. It then connects to a database, creates a file called “results.txt,” executes a SQL select, writes some of the data from each row to the file and increments the count variable. At the end, we print out the count variable.

There are three closures in that bit of code. They begin on lines 3, 4 and 5, respectively. The first connects to the database. The second creates the output file and the third performs a SQL select, writes the output and bumps the counter. Rather concise code, don’t you think?

Do you notice anything missing from this code? Two very important things are not there: closing the file and closing the database connection. I said these bits are not there, but they really are. The block version of DBI.connect ensures that no matter how events unfold, either successfully or with an exception, the database connection will get closed. Similarly, the File.open ensures the file will get closed. This is one of the most beautiful aspects of languages that support closures.

As I said earlier, Groovy has closure support baked in. While I’m not completely thrilled with the syntax, it’s close enough to Ruby’s that it’s not bad. As I was writing this post, I was surprised to discover that Groovy’s SQL module doesn’t support a closure passed to the connection, which means you still have to worry about closing your connection when you’re done. Anyway, Groovy’s file-writing idiom looks like this

new FileWriter(&quot;results.txt&quot;).withWriter {writer -&gt;
  writer.write(&quot;... interesting data ...&quot;)
}

I don’t really like using the -> as the closure parameter delimiter; I’d rather use a | (pipe symbol) like Smalltalk and Ruby do. Regardless of syntax differences, that’s how you write the file, but what about the SQL stuff? Since we can’t use a closure, it’s a bit more involved.

con = Sql.newInstance(url, user, pass, driver)

try
{
  new FileWriter(&quot;output.txt&quot;).withWriter {writer -&gt;
    con.eachRow(&quot;select * from foo&quot;) {row -&gt;
      writer.write(&quot;Foo: ${row.id}n&quot;)
    }
  }
}
finally
{
  con.close()
}

You can see that even though we can’t use a closure to ensure the database connection gets closed, there are still two closures in use. The one beginning on line five opens the file, while the one beginning on line six writes out some of the data from each row returned by the query. Pretty nifty, eh? I’m disappointed that Groovy doesn’t support passing a closure to the database connection, but maybe we’ll get that in a future version.

For comparison, here’s how you would write this program in straight Java.

Connection con = null;
Statement stmt = null;
ResultSet rs = null;

try
{
  Class.forName(driver);
  con = DriverManager.getConnection(url, user, pass);
  stmt = con.createStatement();
	
  rs = stmt.executeQuery(&quot;select * from Foo&quot;);
	
  PrintWriter writer = new PrintWriter(new FileWriter(&quot;output.txt&quot;));

  try
  {
    while (rs.next())
    {
      writer.println(&quot;Foo: &quot; + rs.getString(&quot;Id&quot;));
    }
  }
  finally
  {
    writer.close();
  }			
}
catch (Exception e)
{
  e.printStackTrace();
}
finally
{
  try
  {
    if (rs != null)
    {
      rs.close();
    }
	
    if (stmt != null)
    {
      stmt.close();
    }
	
    if (con != null)
    {
      con.close();
    }
  }
  catch (Exception e)
  {
    e.printStackTrace();
  }
}

The majority of that code deals with cleaning up when the real work has been finished. I don’t know what Java’s closures will ultimately look like, or if we’ll get them at all. I’m hopeful, though, that we’ll get a decent implementation, and can then jettison code like you see above. (I know that using Hibernate or some other mapping tool can eliminate code like this, but not every situation needs that type of framework.)