Tag Archives: closing

Live from TSSJS – Closing Keynote

Posted on by
1

Currently sitting listening to Cameron McKenzie, the MC this event, who is presenting the final keynote for TheServerSide Java Symposium.  Jeanne and I both missed out blogging during the previous session as she was giving her talk on process management and I was taking part in a client-side web panel discussion.

1.  Pervasive Java

Cameron says, “The Learner Will Eclipse the Teacher”, and he’s referring to the fact that Java is being used in new and unique manners.  New frameworks and languages are being built on top of Java and gaining support from active communities every day.

Cameron also quotes James Gosling, who gave the opening key note for the symposium and said, “You can create whatever you want”.

2. Job Security
Cameron talks about the most desired Java-based skill sets on monster, such as WebSphere, EJB, Spring, etc.

3. A Year of Revolutions
Cameron reminds us that in the past year, the technology of today helped to spawn the types of revolutions that haven’t been seen since the printing press.  In this manner, the revolutions may not have succeeded with the technology.

Cameron compares today’s developers to the first printing press, or in more nerd-like terms, Star Trek’s Zefram Cochrane, who brought a new age of human civilization based on fundamental changes in technology.

4.  We’re driving the revolution
Developers have become very democratic and community oriented and have helped grow technology in very unique and often unexpected ways.

Even though we might not be the developers who wrote the social media applications Egypt and Libya used, we have contributed in our own ways that have driven the ‘moment’, such as posting, bug fixing, flaming posts, helping, as well as drinking and socializing.  He joking points out, the Greek meaning of the word Symposium is a social event of drinking and celebration.

Cameron points out that there are certain things we should and should not judge.  For example, if Facebook changes its privacy settings, we should be judging it to know if we’re all effected by the actions of that company.

5.  Life as a Java Developer
Cameron tells a story about Hennig Brand who discovered phosphorus while searching for gold, by boiling urine and experimenting on the residue.  The result was one of the first elements in history to be isolated, that doesn’t occur free in nature.   Cameron then says that for a Java Developer, “Every day is like boiling massive vats of urine”, which received much laughter from the audience.

6.  We are the Revolution
Cameron tells the story about how companies trade, use, and track user information, often without their knowledge.  Companies then make decisions about this data that effect customers but never openly admit how they arrive at these decisions.

Cameron was working in Canada and discovered personal data was being transmitted and despite promises of protection, none of the data was secure.  He wrote letters and spoke up and was able to get the company to slow down and reconsider its plan.

Conclusion
Cameron concluded the talk by thanking the sponsors, vendors, speakers, and participants for taking part in the symposium and helping to build a better, stronger develop community.

Finally Closing of JDBC Resources

Posted on by
8

I love reading Alex’s The Daily WTF and I noticed the recent Finally WTF is relevant to JDBC in an important way. All *good* JDBC developers already know you should close your result sets, statements, and connections (in that order) in a finally block when you are done with them, but do you all know how they should be closed? In particular, while a finally block will be entered under most circumstances, there’s no guarantee every line of code will be executed. Consider the following code I often come across:

Connection con = null;
Statement stmt = null;
ResultSet rs = null;
try {
     // Do stuff
     ...
} catch (Exception e) {
     // Do exception recovery stuff
     ...
} finally {
     try {
          rs.close();
          stmt.close();
          con.close();
     } catch (Exception e) {  }
}

Now, can you figure out what’s wrong with this code? Imagine if the result set rs is never populated and stays null. The first line of the finally block will throw a NullPointerException, and the stmt.close() and con.close() will never be executed. In other words, your failure to close a result set would lead to a connection never be closed even though it was in a finally block! Sure the code is guaranteed to enter the finally block, but if it fails on the first line, the rest of the code will be skipped. Next, compare this other common but still incorrect solution:

...
} finally {
     try {
          if(rs!=null) {rs.close();}
          if(stmt!=null) {stmt.close();}
          if(con!=null) {con.close();}
     } catch (Exception e) {  }
}

This solution is a little safer in that it avoids NullPointerExceptions, but it’s equally as useless as the first solution in that there are a number of reasons why the first line of code could still fail, for example if the result set is already closed. This solution actually worries me the most because clearly the developer went through the trouble of setting up the finally block and null pointer catches, but failed to fully understand how a finally block works. Now, I present a superior solution:

...
} finally {
     try {rs.close();} catch (Exception e) {}
     try {stmt.close();} catch (Exception e) {}
     try {con.close();} catch (Exception e) {}
}

Now, is this solution safe? See that if rs or stmt fail to close, the call to con.close() will still be executed. Granted you could get fancy by adding logic to handle/log the exceptions or even catch Throwable (although catching Throwable’s never a good practice), but that’s a bit overkill. You could also nest your finally block with more finally blocks (just add finally block to the rs’s try/catch and put the rest inside it… and so on) although I tend to prefer this solution since it’s more readable.

Lastly, you could make helper methods for closing the the objects to make the code easier to work with such as:

...
} finally {
     DBUtil.close(rs);
     DBUtil.close(stmt);
     DBUtil.close(con);
}

Where the try/catch is inside the helper methods. Keep in mind this last solution isn’t really different from the previous solution, just a code management improvement.