28 Aug 2007
I’ve been on vacation for the past week or so and took a couple hours to play around with Guice.
Guice != Spring Framework.
For those that don’t know, Guice is a light-weight dependency injection framework. What separates it from a few other frameworks is its reliance on annotations and code-based constructs for wiring together dependencies. There is no XML-based approach to configuration. If you’re one that takes to reading code over xml files, you’ll have no problem adjusting. It took all of a single page of the first tutorial I found for me to get the jist of it and start implementing a simple app.
It’s light-weight in the sense that it does dependency injection and little more. Ensure that the jar is on your classpath and you’re set. If you want web services, advanced AOP, etc. than you’ll most likely be the one having to locate and wire in suitable service implementations.
There’s a good Google Tech Talk that covers Guice in more detail.
Having worked with a couple of Spring projects of various sizes, I can attest to the belief that there is overhead in maintaining configuations in various XML files. However, that’s not to say that a strictly code-based approach would be preferred in all cases, it’s merely an alternative. Having worked with Spring for a couple years now, I’d probably go back and take what I’ve learned and improve existing configurations before considering a more drastic change in configuration strategies. I should mention that Spring JavaConfig does allow you to mix & match code-based and xml-based configurations.
There was a decent post a few months back over on SpringLoaded that did a simple side-by-side comparison of Guice and Spring JavaConfig. JavaConfig is basically an extension to the core Spring framework that allows you to create an annotation-backed ApplicationContext.
Both JavaConfig and Guice do make fairly heavy use of Java5 annotations. Guice is arguably more intrusive as it’s annotations must be inserted into your application code. For example, if you wanted to use setter injection on a class, you would actually add an @Inject annotation on the setXXX() method. Likewise, if you wanted to apply an AOP interceptor to a method, you’d annotate the method and setup the appropriate binding call.
In Guice, you configure an Injector (a quasi-service locator class responsible for providing populated object instances) with an appropriate configuration Module. The Module contains all (or a subset in the event that you’re using multiple Modules) object binding configurations. A binding is essentially a simple mapping of interface to implementation (ie. bind(SomeInterface.class).to(SomeInterfaceImpl.class)) with an optional context.
You also have a central configuration class in JavaConfig but gone is the instrusiveness associated with changing existing application code. The JavaConfig Configuration class implements each required bean as a method (ie. public SomeBean bean1();). It’s up to the implementor of these methods to ensure that appropriate dependencies have been injected. There’s an important trade-off to be aware of here between what’s provided by the framework and what’s expected of the implementation. I must admit that I prefer JavaConfig’s handling of interceptors via a Spring AOP point cut expression to Guice’s annotation.
In the end, I do more or less agree with Craig’s conclusions. There’s some interesting commentary from both Colin (Spring) and Bob Lee (Guice) that is also worth checking out. Given how widespread the use of Spring is, it’ll be interesting to see how the JavaConfig extension plays out (currently it’s 1.0m3).
If I were starting a personal project today, I’d seriously consider using Guice if I needed a dependency injection framework. It’s simple and certaintly fits the bill. Plus, it’s already available in a public maven repository (although JavaConfig is also available via. the Spring Framework’s own repository).
Mmmm new and shiny frameworks!
07 Aug 2007
I went to school in Canada so we didn’t any of the controversy that’s currently brewing down at S. Carolina.
Their football coach, Steve Spurrier, is upset because two of his recruits were not admitted to the University based on their academic standing. The University managed to deny them admission despite them satisfying the NCAA minimum requirements.
I agree with the stance taken by the University and question why this is even getting air time. It’s very rare to see a student athlete turn pro and make a decent living, far more often these athletes finish their 4 or 5 years of eligibility and join the working world like the rest of us. The University would be doing them a disservice by not emphasizing academics. Further to that, there is the possibility for penalties (in the form of lost scholarships) if athletes drop out prior to completing their degree.
The following was a comment from the ESPN article (every other comment was in favor of the action, this one wasn’t):
Who cares what their GPA and test scores are. They chose the school to play football and not for their academics. I think that college admissions criteria for athletes should change. If an athlete chooses to go to a university for a sport, then that sport should be the major with their own admissions requirements (college of athletics). On the other hand, if an athlete does choose a ‘regular’ major then he/she should be held to the same academic standards that non-athletes for that major are held to. Having an athlete be held to an academic standard is like having a computer nerd squat 600lbs or practice with the football team (ain’t gonna happen even if you could get him out of his mom’s basement).
*Funny stuff. * Latest news has South Carolina stating that it’s willing to work with Spurrier but is not prepared to re-write the admissions rule book to do so. Nor should it.
04 Aug 2007
Funny story, and a lesson on something to watch out for when dealing with Swing tables and event listeners.
Scenario:
Given a JTable, suppose you want to add some functionality to select all the wells on the table. Of course, it’s not just as simple as selecting every well, you only want to select the wells that have contents.
Pseudo code:
setSelectedWells(table, wells)
{
table.clearPreviousSelection()
for well in wells:
table.selectCell(pair.x, pair.y)
}
Pretty simple right? Swing complicates the matter a bit further with column and row selection models so the equivalent of table.selectCell() actually involves the setting of selectionIntervals on the underlying row and column ListSelectionModels.
If you’ve worked much with Swing components, you’ve no doubt realized that it’s very easy to perform operations that generate significant #’s of events. Not a slight on Swing, it’s a powerful (and fairly complex) GUI toolkit and it’s important to understand it’s eventing framework whenever you’re writing non-trivial pieces of code.
The above example is no different, as your changing selection intervals on the row and column ListSelectionModels you’re going to be generating a change event. If you’re doing this in a loop, you’re going to be generating multiple events per iteration (one for row, one for column). However, you still won’t see a problem until you have a handler tied to those selection events. Suppose your handler performs a quick(?) operation that takes a tenth of a second. Regardless of whether or not the business logic is backgrounded or executes on the EDT, you’re going to see a significant slowdown with any significantly sized table. Take a table w/ 384 possible placement locations, depending on the implementation you could theoretically have 384*2 event notifications generated (again, one for row and one for column). If the response to each of those notifications took a tenth of a second, you have what aggregates to a 77s operation.
To cut to the chase, Swing allows you to treat a situation like this (changing selections on a per iteration basis) as a single batch through the ListSelectionModel’s ValueIsAdjusting flag. What this flag essentially does is provide a hint to the handler/listener that the source of the event is still adjusting. If a source value is still adjusting, chances are that a response is not necessary until it’s reached a final state. This is fairly typical of a drag operation, where you’d want to respond when the user finishes their drag operation, not after each element is selected. Using the valueIsAdjusting flag is easy, simply set it to true before prior to your selection event generating logic, and to false when your done (or better yet, store the current state of valueIsAdjusting before and restore it after). Whenever valueIsAdjusting changes (true -> false or vice-versa) an event will be generated, so you don’t even have to do anything else.
Just making this change in the system I’ve been working on turned a 100s operation into a .2s operation. The funny part was that this seldom used operation (wonder why it was seldom used?) had actually been in the system for years.
As the community moves towards more consistency in our usage of Swing (motivated by the availability of frameworks like the Swing Application Framework), one hopes that the learning curve diminishes and application developers are able to focus more on their writing of domain-specific code and less on the intricacies of the UI underpinnings.