Really Cool Site Containing Java Conference Videos

Yesterday I stumbled upon It appears that Parleys has been around for a while, providing podcasts of various tech presentations (audio only). However, the new version of the site, still in Beta, takes their offerings to an entirely new level. It now contains several videos of presentations from various Java conferences over the past few years. Not only is the content fantastic, but the user interface is very slick as well. The UI displays not only the audio in sync with the slides, but also a video of the presenter, giving you the full experience. The navigation options are also great, providing a table of contents and a time line for the presentation…letting your jump to a specific point in the talk. In addition, Parley’s provides information about the speaker and the talk, a list of related talks, and the ability to post tags and comments at specific points in the talk.

In my opinion, the best feature provided by is the ability to watch the presentations, with all of the UI features, offline. This is HUGE for me, as I spend almost two hours every day sitting on a train. Parley’s provides an Adobe AIR application that makes all of this possible. Adobe AIR is a runtime environment that “lets developers use proven web technologies to build rich Internet applications that run outside the browser on multiple operating systems”. The Linux version of AIR, still in Beta, works wonderfully. The AIR application operates just like the site, and provides some additional functionality to download the presentations for later viewing.

I’ve been spending quite a bit of time lately looking for a site like this. With the current economic conditions, I’d imagine that most companies are cutting back on the number of conferences they send their developers to. According to the site, they plan on continuing to add content. If they do, I see this as an invaluable resource for keeping up to date on what is going on in the Java community.

Great Post on the Concurrency Hazards of Stateful Web Applications

When people think about stateful web applications, I believe that most of the concerns usually focus on the scalability of that web application. Stateful web applications are more difficult to scale out, as you need to ensure that all requests from the same session are handled by the same application instance, or you need to setup some mechanism so that instance A can pick up and resume the session that was started by instance B, creating a potential bottle neck.

However, with the new breed of web applications out there that allow a session to be sending multiple, possibly concurrent requests (via practices like AJAX), a new crop of concerns arise. Most (if not all) web containers take care of managing concurrency concerns between sessions. But, most do nothing to manage concurrency concerns within the same session.

Java concurrency master Brian Goetz provides the details at

Overriding Java methods in Groovy for unit testing

Lately, I’ve been experimenting with writing unit tests in Groovy to test our Java code at Orbitz. Groovy provides many nice language features that have the potential to dramatically reduce the amount of test code that you have to write, and to decrease the maintenance burden of that test code. Since it makes tests easier to write and maintain, hopefully more people will do it! :)

One of the features of Groovy that immediately caught my attention was the ability to specify a new implementation for a method of a given class at runtime. I was first introduced to such power by Ruby, and have been wanting it elsewhere ever since. I immediately thought that this would be great for testing our legacy code, where stubbing methods is difficult, yet often necessary to avoid major refactoring work. Changes involving major refactoring take much more time and increase the possibility of introducing more bugs. This codebase is in the middle of being swapped out with a new one, so a major refactoring isn’t really worth the effort (it would however be worth the effort in the new codebase). Currently, to stub out private methods buried in our codebase, we’ve been widening the accessibility of the method to protected, and subclassing the class to override the functionality. I’m sure this seems hacky, but it’s really less risky/evil then some of the alternatives. The code under test in this case is back end code that is not available outside of our team. Obviously, widening the scope on a method of a released API or library would be a different scenario entirely. So, I was really excited to think that Groovy could possibly help us with this nastiness.

Sound too good to be true? Well, it is.

This great feature is only available for Groovy objects! Java objects need not apply. You can add methods to Java classes, but you can’t change them. Bummer.

While scouring the web to see if there was any other way to do this, I stumbled upon JMockit, a library that helps with unit testing in Java. JMockit lets you do exactly what I want to do; provide a new implementation for any method on a class! Private methods, static methods…no sweat. JMockit to the rescue!

Right? Wrong.

Exception in thread "main" mockit.RealMethodNotFoundForMockException:
Corresponding real methods not found for the following mocks:
groovy.lang.MetaClass getMetaClass(),
Object invokeMethod(String, Object),
Object getProperty(String),
void setProperty(String, Object),
void setMetaClass(groovy.lang.MetaClass)

With JMockit, the mock object containing the new implementation must not include any new methods that are not on the original class. The problem here is that all objects in Groovy contain several methods that are not on java.lang.Object. So, even though you are not programmatically adding methods to the mock that aren’t on the original, since your object is automatically a GroovyObject, it has these new Groovy methods, whether you want them or not. And, specifically extending java.lang.Object doesn’t help either. So, back to square one.

But, all hope is not lost. Sure, it sucks that we’re reduced back to widening the accessibility of a method so it can be stubbed out in a subclass, but at least doing this is much easier in Groovy. Take the following Java class for example:

public class Book { 
    public String read() { 
        return getLine(); 

    private String getLine() { 
        return "Damn this is a long book!"; 

What if we want to have getLine return something different? Well, first we have to make it protected:

    protected String getLine() { 
        return "Damn this is a long book!"; 

Then, we have to subclass Book and provide the new implementation. The easiest way to do this in Java would be with an anonymous inner class:

Book b = new Book() { 
    protected String getLine() { 
        return "Short book"; 
assertEquals("Short book",; 

This is much more concise in Groovy, thanks to closures, map coercion, and the fabulous “as” keyword:

def b = [ getLine: { "Short book" } ] as Book 
assert "Short book" == 

Not only is it less code, but it also protects us from interface changes to getLine! getLine can be changed to take a parameter or throw a new checked exception, and our test would remain unchanged, lessening the maintenance burden of our test case. Very nice.

So, although this is not ideal, it still has benefits over its Java counterpart.

I’m spoiled

Wow, I’m spoiled. Spending the past several years working with Java, Ruby, Erlang, and some others, I’ve grown accustomed to the hoards of free libraries and tools out there just begging to be used. IDEs, code analysis, continuous integration, frameworks, profiling, testing…pretty much anything you could ever want. This rings especially true for Java, since it has been in the limelight for so long. So, I was shocked to find out that there doesn’t appear to be a free comprehensive code coverage tool out there for .NET.

As I’ve mentioned before, I’m writing a test suite for Shotokan Karate of America‘s new membership administration system. The application is written in C#. The pace of development has picked up lately, and new code is being released for testing about every couple of weeks. I’m not too involved with the development of the application, so I don’t have much insight as to what has changed from release to release. So, I’ve been looking for a good code coverage tool to show me areas of the application’s code that I may be overlooking in my tests.

I wanted something like Cobertura for Java, which has a rich set of features, and a set of easy to read code coverage reports. But, the only thing I could find that even came close to Cobertura was NCover. Free? Nope. Try $149 a license. Oh…wait, you want the one with the HTML reports? That’s $299.

I’m new to .NET, so naturally this raises a bunch of questions. Is this the status quo in the .NET community? Is everything pay to play? How does this affect the community? If Joe Developer has a library that he thinks others might find useful, does he slap a price tag on it simply because that’s the way things are? How do free open source software projects in .NET (I’m assuming there are some) get started? Does this type of model encourage or discourage community involvement in a project?

Is it just me, or does anybody else think that it sucks to not have these tools freely available to the development community?

I should note that I am a giant tight wad. Don’t believe me? Ask my wife.

A theme at JavaOne – Beyond Java

I noticed a few themes at JavaOne this year. One of the big ones was JavaFX. It had sessions galore, and plenty of stage time at the general sessions. But, another theme I picked up on was the amount of sessions dedicated to non-Java programming languages; perhaps a bit odd considering this was JavaOne.

JRuby and Groovy were all over the place. There was also a session on Scala. These other languages bring new ways of solving problems to the table. In addition to their expressiveness, JRuby and Groovy bring the power of meta programming to the Java world. Scala also brings a more expressive syntax, and the power and flexibility of two programming paradigms: object oriented and functional.

These were the only non-Java programming languages that had sessions associated with them. At the CommunityOne session I attended which was presented by Charlie Nutter, Charlie said that virtually every language out there is capable of running on the JVM, usually via a sub-project. I think this is a very profound statement. It shows that the language implementers or those strongly associated with the language realize the benefits of running on the JVM, and the ability to integrate with the billions of lines of existing Java code out there. Granted that each one of these projects varies in the level it can interact with existing Java code. However, Sun appears to be making a strong effort to work with the implementers of these languages to make integration with Java easier.

I think this is great. I’m sure that Sun realizes how powerful and mature the Java platform has become. And, as a Java programmer, I love the idea of being able to pick a language that best fits the problem I am trying to solve, while still maintaining interoperability with my existing Java code.

The Java language itself appears to be stalling. No widely adopted programming language lives forever. In order for a language to be successful, it must maintain some sort of backward compatibility. Maintaining backward compatibility, while necessary, slows the evolution of the language, and prevents the language from adopting vastly different programming models that may be a better fit for new problems that developers may be facing. Newer languages, or less widely adopted languages, do not face this dilemma and can change more rapidly. I’m also unconvinced of the effectiveness of the whole JCP process. I some situations I feel it is best to have a small group of intelligent individuals at the helm of a project, making all of the decisions. Usually, the more people involved, the longer it takes to get things done.

I think that making the JVM a more attractive environment for non-Java programming languages will only benefit the platform. I think it will also prevent some developers from jumping platforms to use a different programming language that better suits the problem they are trying to solve. I think this is a win for the Java community.