Google's Guice
One of the blogs I read occasionally is written by Bob Lee, a Java programmer who works for Google. Recently, he announced the release of Google's Guice 1.0, a dependency injection framework built around annotations with support for generics. Why is this significant? To me, it's significant because I've grown to appreciate the productivity benefits of solutions built on annotations (Stripes, for instance) versus their XML alternatives (Struts, etc.). In this case, Guice is going up against Spring, or at least some of Spring.
At this point, I have little to add because I haven't used Guice. If you've read my article on Spring, though, you know I use it as more than a dependency injection framework, and I can envision Guice having a tough time pulling me away from Spring because of it. Nevertheless, it will be on my mind as I dig into new projects as a possible time-saver.
Posted at 03:41PM Mar 13, 2007 by Jason Koeninger in Java | Comments[0]
Our Java Stack: Hibernate
JDBC held its place as our primary data access technology far too long. Having grown up in C/C++ programming, JDBC felt like the natural replacement for ODBC. Unlike ODBC, we didn't wrap JDBC up in our own class library which seems odd in hindsight, and it led to some problems in production applications. As soon as you experience a few traffic spikes in an application with connection leaks, it becomes obvious why you should have wrapped JDBC in a library. We waited long enough, though, that a great number of competent libraries already existed.
The two tools we reviewed were iBatis and Hibernate. As a bit of a SQL jockey, I really liked the level of control offered by iBatis, but the potential productivity benefits of Hibernate (no SQL coding of CRUD operations) won out in my evaluation.
In November 2005, I dove into a new project with Hibernate 2.x as the data access layer. After spending a few months with Hibernate, I hated it. Yes, you read that right. I hated Hibernate. To be honest, I think some of my problems with it were of my own making and not necessarily the fault of Hibernate itself, but I could never see using it again. In March 2006 on the doorstep of switching to iBatis, I found Hibernate Annotations and decided to give Hibernate sans-XML configuration another shot.
Even though some of my issues with Hibernate remain (and remember, they're probably my own ignorance), Hibernate Annotations earned Hibernate a semi-permanent spot in our Java stack. I know there are arguments for and against code-based configuration, but the simple fact of the matter is that I am more productive using annotations.
Posted at 05:29PM Mar 06, 2007 by Jason Koeninger in Java | Comments[2]
Our Java Stack: Swing User Interface
With most of JJCC's work dominated by web applications, it's a rare opportunity to step away and work on a rich client. Health Occupation Students of America provided just such an opportunity a little over a year ago. The design for the HOSA Conference Management System called for a thick client capable of running stand-alone while staff worked on-site at the conference. The interface did not have to be pretty so much as it needed to be user-friendly and functional, and as usual, time was short.
In past graphical user interface projects, I have used Java AWT, Java Swing, OS/2 Presentation Manager APIs, and the Microsoft Foundation Class Library. I even went so far as to write a cross-platform GUI class library with support for both 16-bit Windows APIs and OS/2. Not looking to reinvent the wheel this time around, I needed to find a tool to build screens and connect them to data much more quickly.
As leery of GUI programming tools as ever, I set out to investigate some of the XUL (XML User Interface) options available. Initially, Mozilla caught my eye with its XULRunner. Being new and somewhat unstable handicapped Mozilla's offering as did requiring Javascript for coding actions. Javascript would have been fine, but there would have been a learning curve.
Having been exposed to XUL by Mozilla, I then started reviewing some of the Java XUL frameworks. Some were too big and cumbersome, others were incomplete or poorly documented, and still others were just too simple. It wasn't until I stumbled onto SwiXAT that I found something that I thought might work.
SwiXAT is not so much an independent project as it is a coming together of several useful parts into a more efficient whole. The basic XUL displays are written using SwiXml, but with SwiXml, you can do little more than mock up the screens. You still have to write code to load and display the screens and process events and actions. This is where SwiXAT shines. It allows you to wire user interface actions and events to BeanShell scripts. It also allows you to populate controls using JavaBeans accessed through JXPath. The end result is a stable, functional application written with a minimum of compiled code.
As long as you are not a GUI design fan, the only downside of SwiXAT is that it isn't all that popular and has not reached a stable version yet. Nevertheless the original architect, Paolo Marrone, remains active and helpful on the mailing list, and I have yet to see an application failure attributable to SwiXAT or its components.
If you're considering a XUL framework, download SwiXAT and give it a shot. You won't be disappointed.
Posted at 12:06AM Feb 03, 2007 by Jason Koeninger in Java | Comments[0]
Effective Java Exceptions at Dev2Dev
Barry Ruzek has written a great article on Java exception handling at Dev2Dev.
Posted at 05:45PM Jan 25, 2007 by Jason Koeninger in Java | Comments[0]
Our Java Stack: Swiss Army Knife (Spring)
Spring is a lot larger than a Web Application Framework. Swiss Army Knife is the best analogy I can come up with for how we use Spring.
Most importantly, we use it for Dependency Injection. Specifically, we program all data access to interfaces and have Spring inject the actual implementation classes at runtime. Early on in our work with ORM tools, we weren't sure which tool we would end up choosing. Having an easy way to keep our service objects independent from the underlying data access was very important to us so that we could switch data access methods if we changed our minds. Programming to interfaces provides endless flexibility, and Spring makes it simple.
As mentioned in the Web Application Framework article, we also use it to annotate transactions. Having experienced problems in older JDBC projects from leaking resources, Spring helped our application stability immensely by taking away an opportunity for programmer error to cause systems to become unavailable.
Other helpful Spring tools are its wrappers for several of the major data access technologies. Right now, we're using Hibernate v3.x, but it also supports other popular tools like iBatis, JDBC, and EJB.
Beyond some of those basics, we also had a few problems pop up in one project which were solved less painfully than normal using AoP (Aspect Oriented Programming). Spring's built-in AoP support meant we could implement some aspects without adding any dependencies to the project, and they saved us the trouble of major architecture changes to get the right information info the right piece of code.
There's little doubt we'll find further use for Spring as the years go by. The nice thing about it is that even if you don't want to use one piece of it, you can still easily use the rest of it.
Links:
Posted at 07:00AM Dec 17, 2006 by Jason Koeninger in Java | Comments[0]
Our Java Stack: Web Application Framework
The last 3 years have been an interesting time for JJCC as we have been working to find a web application framework we can live with. Our home-grown framework was written for a year-long project and was not encapsulated in a way that the code could be used in other projects. Struts was also gaining popularity, and in reviewing it, we found that many of the concepts we used in our framework were provided in Struts. It also provided tag libraries, file-based configuration (as opposed to code-based like ours), and a variety of other useful features like filters on top of what our framework offered. With its popularity on the rise, it seemed like the obvious choice of frameworks available at the time.
Unfortunately, in practice, we found Struts to be cumbersome and error prone. Don't get me wrong...Struts itself was very solid. The problem was that development using it was error prone. Additionally, we often ended up with views that couldn't be re-used in different contexts. The blame for this does not entirely rest with Struts. Indeed, we were part of the problem, but it seemed like we were constantly chasing configuration files. To help with that, we enlisted XDoclet, but it all seemed to turn into a bigger and bigger mess. I don't recall all of the problems we encountered, but we were spending more time on build systems, configuration files, library versions, and troubleshooting the framework than we were on coding.
After most of our projects stabilized, we decided to look at alternatives to Struts. This time, Spring was the new kid on the block with rising popularity. Granted, more of the buzz about Spring dealt with Inversion of Control, but it also came with its own web framework. Our experience with SpringMVC didn't even last through the completion of our first project. It felt like the same maze of configuration files that we had with Struts, and there was no other significant added benefit for the kinds of projects we typically undertake. In truth, we didn't even stick with it long enough to see how well it could have worked. We fought a little with its form handling interfaces with little success and ended up using it as little more than a thin servlet wrapper.
Our experience with Spring did expose us to something we did like, though...Annotations. We had used the Spring Transactional annotation to control transactions in our data layer, and it made life a lot simpler than coding a bunch of garbage into an XML configuration file. While there are some good arguments for external configuration, they just don't apply in our typical project scenario.
By some accident, we stumbled onto the Stripes project before finishing the first SpringMVC project. Stripes is a drastically simplified framework which relies primarily on annotations for configuration. However, simplification shouldn't be confused with lacking power. Stripes allows you to write a form using a small tag library which draws data from JavaBeans defined in your Action. When the user submits the form, Stripes intercepts it, finds the action associated with the URL, automatically converts and binds the form field values to the JavaBeans in the action, runs annotated validations on the values as they are bound, and then executes the handler method in the action.
To a lot of programmers, it's confusing because it seems like magic. Grabbing parameters through the request, converting data types, catching exceptions, handing off to error handlers, etc...all things of the past. Stripes does all of this work for you so you can focus on the application and not trivia. It even adds in goodies like FlashScope which allows you to retain data in the session for a short response/request cycle as you would get when sending a redirect at the end of a form submission to prevent reload/resubmit problems.
Since switching to Stripes, we have cut our estimates for building web-based forms/database applications in half. Try it out and see if you have the same it-just-feels-right reaction to it.
Links:
Posted at 03:22PM Dec 16, 2006 by Jason Koeninger in Java | Comments[0]
Our Java Stack: Introduction
It's amazing how things have changed since I entered the programming field back in 1993. In our first database project, my business partner at the time wrote a hierarchical set of index and flat files. Everytime I pulled up DOS Edit and fixed an indexing problem in the production database, he cringed and sometimes with good reason. The fixes often made the problem worse, not better. When the limitations of our first database caught up to us, we moved into real database territory by consulting the Programmer's Paradise catalog and finding CodeBase by Sequiter Software. Back then, before many software companies even had web sites, companies working in PC software often took that approach. There were several catalog sites selling 3rd party SDKs and APIs in addition to those available through the major operating system vendors. When you found what you needed, you ordered it, consulted the documentation, and wrote the code.
Now, the game is much different. Orphaned operating systems caused us to pull away from platform-specific code...orphaned SDKs/APIs caused us to pull away from commercial solutions. Our only gamble would be the survival of Sun and Java.
When we first made the leap to Java, we did not use any 3rd party tools. At the time, not many were available, and those that were available weren't on our radar. In our first Java web application, we used servlets to a fault making a huge, tangled mess of Java classes. In fact, that was before a lot of the servers on the market supported JSP so the servlets were full of out.println( "..." ) statements.
On the next project, we learned a bit from past mistakes and implemented what could best be described as Struts 0.01. We had never seen Struts, but we ended up creating an architecture with some similarities to Struts Actions but lacking the other pieces of Struts like tag libraries, configuration, and filters. As luck would have it, it has served us well and still runs today. However, it's impossible to look at the code without seeing its shortcomings.
Beyond the web application architecture, we were also reinventing the wheel in other areas. As a result, applicatons were taking too long to design, develop, test, and debug so we set out to find a set of tools to improve our productivity, increase application stability, and simplify code. This series of articles will review the tools we have chosen and discuss a few of the tools we rejected along the way.
Posted at 04:25PM Dec 13, 2006 by Jason Koeninger in Java | Comments[0]