Oracle JDBC PermGen Memory Leak Fix

Let’s talk about the Oracle JDBC drivers. If you have had the misfortune to use them, you know that there are many ways they can taint your well written application. For me, the most annoying problem is the memory leaks they leave behind when you redeploy an application without shutting down the JVM instance. Do this enough, and the drivers end up using all of the PermGen space and necessitating a restart of the JVM (undesirable when your JVM is really a web server running multiple applications). This problem has plagued me for a couple of years, and I think I have finally figured out the solution. I wrote that solution into a library I call SimpleOraclePool.

SimpleOraclePool takes care of creating a connection pool using the Oracle UCP library with the Oracle JDBC driver providing the connection. Included in the library is a ServletContextListener, named OjdbcDriverListener, that will clean up the Oracle mess when your application is unloaded (from a Servlet container, of course).

I’ll leave out the explanation of how to use it. That is all documented in the code repository’s readme and the JavaDoc included with the library. But I would like to sign this post with a message to Oracle:

....................../´¯/) 
....................,/¯../ 
.................../..../ 
............./´¯/'...'/´¯¯`·¸ 
........../'/.../..../......./¨¯\ 
........('(...´...´.... ¯~/'...') 
.........\.................'...../ 
..........''...\.......... _.·´ 
............\..............( 
..............\.............\...

Null Is A Vile Beast

Since my last post on Java I have been learning the Spring web framework. The Restlet detour was very enlightening, and I do prefer that framework, but everything I deal with (insofar as Java web applications) at work is based on Spring. So I want to revisit that post from a Spring based approach at some point in the future. This post, however, is about avoiding the use of null.

While working in Java I have developed a renewed love of types. After working in dynamic scripting languages for so long it is refreshing to write code where you know, as you’re writing it, the exact representation of the data. Sure, you can institute methodologies to suggest types in dynamic code; but those are easily broken for any reason. For example, this bit of JavaScript:


(function() {
  var aNumber = 0,
      foo = function(){};
  
  foo = function(x) {
    if (x > 0) {
      return x*x;
    } else {
      return "Invalid number";
    }
  };
  
  aNumber = foo(2);
  console.log(aNumber); // 4
  
  aNumber = foo(-1);
  console.log(aNumber); // "Invalid number"
}());

Someone looking at the variable definitions would expect aNumber to always be a numeric value, but someone has come along and given it the possibility of being a string value as well. This isn’t necessarily a bug, but it can turn into one fast, and be difficult to track down. Explicitly types solves this problem before the code is ever executed — it just won’t compile.
Continue reading ‘Null Is A Vile Beast’ »

CacheViewer Continued is… Discontinued

This is a short post to notify the users of CacheView Continued that I have decided to officially stop supporting the add-on. In my last post on the subject I said that I wanted to keep the add-on going because it is invaluable to the users of Firefox that need it. That wasn’t a lie. But my schedule is completely full. I just don’t have the free time necessary to fix any of the major problems with CacheViewer Continued.

I had hoped that others would contribute to the project. That’s why I provided a public repository for the project. And that repository will live on for anyone that wants to pick the project back up. But let me warn you, developing a Firefox add-on such as this is no picnic; and it’s Mozilla’s fault.

A Note On Java Culture And A RESTlet Tutorial

My first real experience with web development was based on PHP. I opted to learn it over Perl because it was more popular at the time and its syntax is very similar to C. One of the things I liked most about PHP was the excellent manual on the official website. The tutorial at the start of the manual was all I needed to get started, and the rest was a great reference. It did, however, take a long time to learn what constituted bad practice with the language. But, I digress.

Nowadays I find that I have to work with Java as a web development platform. The major third-party platforms we use at work are almost always written in Java, or at least against the JVM, so it’s basically what I am forced to deal with. Before being forced to deal with the Java platform in this manner, I didn’t think much of it at all. In fact, I would usually deride it. There are some tools written in Java that I liked, and used, but overall I just wished it would go away. But that attitude has been changing.

Let me backtrack a little. I mentioned that most of our third party software is developed in Java. Well, most of our in-house software is not. No, most of our in-house software is developed in .Net. I thought I wouldn’t mind working with .Net, at first. C# is actually a rather nice language, and the .Net framework has a lot of useful libraries. But then I tried to do web development in .Net. I have never seen a bigger mismatch of technologies than .Net and the web. The .Net name is a total misnomer. It was clearly designed for traditional application development with web development tacked on after-the-fact.

So, I was primarily a PHP web developer in a .Net house that has to manage some Java web applications. Clearly, something had to give. Well, as I spent more time with the Java applications, and learned how they are developed, I started to like the platform a little more. It became clear to me that the Java platform is much better suited to web development than the .Net platform. Thus, I have been trying to learn how to properly do web development with the Java platform.

Notice that I said “trying” — it hasn’t been easy. The Java platform comes from a corporate environment. As such, the knowledgable developers of, and community around, the platform are steeped corporate ways and thinking. This means it is very difficult to find good, free, information on the web, but very easy to find a million overpriced books. Not only that, but all of the innovation has happened in the free spaces like PHP, Python, and Ruby (gee, I wonder why?). So you’ll find a lot of stuff implemented in Java, because the folks working with Java would like to play with the new toys, but no documentation for the Java implementations. This means there are hundreds of ways to get started in Java web development but no clear path.

Anyway, as I mentioned a few posts ago, I had a new idea in mind for a project at work and came to the conclusion that it would be best done in Java. Mostly because I can’t stand .Net more than Java, and because I need to learn how to properly develop web applications in Java for some third party stuff we’ll be dealing with at work soon(ish). This project was to be a web API, and I wanted it to be a “RESTful API“. So I started researching Java APIs.

I started out trying to use the Spring framework because it is the basis for pretty much every major web application developed in Java nowadays (including the third party stuff I’ll have to deal with soon). But that is an exercise in frustration. So I decided to try something else just so that I could actually accomplish something. Thus, I came across the RESTlet API. Again, the API is very poorly documented, but it looked rather clean. So I read the book and found myself really liking the API.

It’s worth noting that the RESTlet site, at the time of this writing, has been updated with a much better tutorial than when I started learning the API a month ago. Evidently the site was, and still is, really, undergoing some major updating. So it is possible to get started with the API without using the book, now.

However, I still think the tutorial is lacking. It doesn’t really show how to use the API. It imparts some information that you really should know, but it doesn’t help the person that just wants to “write a damn application.” So after getting basics of the API figured out myself, I decided I would write a tutorial.

Before I link you to my tutorial I should briefly discuss the format of it. I hate it when a tutorial is basically just a link to some source code. But there really isn’t a better way of introducing this topic (unless you want to write a book). So my tutorial is mostly source code, but I did it a little differently. The tutorial itself is in the comments of the source code, with an overview of the technology, and how things are put together, in the text only part. Additionally, the source code isn’t tucked away in some damn zip file you have to download or just in a web browsable directory. I put it in a Mercurial repository and hosted it on BitBucket. So it is browsable, easily updatable, and you can see the history of the tutorial.

Without further ado the tutorial — https://bitbucket.org/jsumners/restlet-2.1-demo.

I hope you find it helpful. And if you can think of any way to improve it, feel free to send me your suggestions via a pull request.