JavaOne 2008 – Day 2

Oracle General Session Enterprise Application Platform

Here is my summary this session:

Buzzword, buzzword, buzzword. Look at this fancy GUI tool you can use to create applications without writing code. Buzzword, buzzword, buzzword. Look how well this integrates with Excel. Buzzword, buzzword, buzzword. Give us lots of money to make your life as a developer as mundane as possible. Bleh.

Developers like writing code. We WANT to know what is going on behind the scenes, and we WANT the ability to completely control that behavior. I think the presenters forgot where it was that they were actually presenting.

Groovy, the Red Pill: Metaprogramming–How to Blow the Mind of Developers on the Java Platform

Sorry Charlie (Nutter), but you just lost the “Best of JavaOne” title to Scott Davis (although, I still REALLY liked yours). This presentation was fantastic. Not only is Scott a very engaging, enthusiastic, and funny presenter, but the material was great. In the matter of an hour, he was able to shoot through many of Groovy’s strongest features.

For those new to Groovy, it is a dynamic programming language that runs on the JVM which has FULL interoperability with Java. Groovy IS Java in the sense that the Groovy is converted Java bytecode before it is run. Groovy can use Java libraries, and Java can use compiled Groovy libraries. Groovy is also able to run valid, syntactically correct Java code. This enables you to start using Groovy with your existing Java coding style. Then, gradually, you can start to use some of the features that make Groovy such a remarkable language. This ability to “ease into” the language is one of Groovy’s greatest strengths.

What are some of these “cool features” you ask? Method pointers, closures, dynamic addition of getters and setters, operator overloading, the ability to dynamically add methods at runtime (even to Java standard library classes), the ability to handle calls to methods that don’t exist, and much, much more.

These capabilities allow you to create domain specific languages that let you code much closer to the problem domain, increasing the readability and maintainability of your code. Scott took us through an IPod example, where an IPod object lets you load songs onto it. Say we have an ArrayList of songs, named songs. “songs.add(new Song())” doesn’t really express what we want to do. We want to “load” a song onto the Ipod, not add a song to the list of songs on the IPod object. So, we can create a new method pointer, named load, and point it to the add method:

load = songs.&add

This lets us code much closer to the domain, loading songs onto the IPod by calling songs.load(new Song()). Very cool.

But, the true power of Groovy, as demonstrated in Grails, is its metaprogramming capabilities. Want to add a new method, shout, to java.lang.String? No problem:

String.metaClass.shout = { ->

Methods can be re-defined in a similar way. Re-defining methods gives you a way to easily stub out methods for testing.

Groovy also provides hooks into methods that either allow you to do something before a method in a class is invoked, via invokeMethod(), or when a call is made to a non-existant method on a class, via methodMissing(). These capabilities allow you to intercept method invocations, add dynamic behavior based on a methods name and/or parameters, and more.

Groovy also adds TONS of syntactical sugar on top of Java. Easy iteration of collections, overloaded operators that just make sense, additional operations to the Java Standard Library classes, etc. All of this, and more, is what makes Groovy such an attractive programming language. I’m looking forward to learning more.

Introduction to Web Beans

What is a web bean you ask? That’s a good question. Even after attending this presentation, I’m not quire sure that I know the answer. Web beans appear to be a way to make services available to a client in a way that is non-invasive, and in a way that prevents tight coupling. Service implementations can be injected into a client for use in any layer of the stack, without the need to go through layers upon layers of middle-ware. I’m sorry to report that this is all I got out of this presentation. I will likely review the slides from the presentation and read up on the subject on the web after JavaOne to see if I can learn more about this, as I am disappointed that I sat through this hour long presentation and still do not know that a web bean is.

It’s All About the SOA: RESTful Service-Oriented Architecture at

The folks at gave a good presentation about their use of REST in their service oriented architecture. They moved to an SOA from a monolithic, self contained application (written in a single C file!) to eliminate business logic duplication and the drifting of that logic into other areas. SOA also helped with the isolation of sensitive data, reduced coupling (which enabled easier cross team development via interfaces), and provided a service level domain focus.

Before choosing REST, evaluated some competing SOA technologies, including SOAP/WS-*, JINI, and a few others. REST won out for a couple of reasons. First, they liked that it provided a uniform interface (which is basically HTTP). Also, they wanted to take advantage of their experience as web application developers who already had detailed knowledge of the HTTP protocol. Since they were already familiar with the technology (HTTP), it enabled them to get them up and running quickly, which was a requirement due to an approaching holiday shopping season.

They developed a web framework, built upon the open source Restlet REST framework for Java, to take care of some routine operations that they did not want to burden their developers with. For example, since they didn’t want to muck with the XML directly, their web framework took care of marshalling/unmarshalling the XML to/from their object model via JAXB. It also took care of some logging, and other common concerns. In addition to developing their own framework on top of Restlet, they also contributed code to the Restlet project, and to the JAXB project.

One of their goals was to keep things as simple as possible. Their solution was developed in J2SE, and is deployed via Tomcat web containers, with standard HTTP load balancing. They are able to perform rolling deployments because they always maintain backward compatibility with at least the last version of the application.

Dealing with Asynchronicity in Java Technology-Based Web Services

This presentation covered a technique that was developed to deal with asynchronicity in web services. I must admit, one of the reasons I signed up for this session was to find out what “asynchronicity” meant :) Using asynchronous web services adds complexity, but also provides some benefits. For one, you don’t have to sit there and wait for long running services to complete. You can call the service, and immediately return so that you can do something else. Second, using asynchronous web services gives you the ability to cancel requests at any time.

There are two ways to implement asynchronous web services. The first involves polling. The client will call a web service, which will queue the request for processing, and immediately return to the client. With polling, the client will periodically check back with the server, via another web service call, to see if their request has finished processing and to retrieve the result. This has many issues. It is chatty, especially when you’re dealing with multiple clients issuing multiple requests. It also adds unnecessary latency, as there may be a period of time that passes after the request finishes processing, but before you make the call to retrieve the results.

The second technique, the one covered in detail during the presentation, involves a callback from the server. This technique involves the server exposing the web service, as normal, AND the client exposing a callback web service. When the client calls the server’s web service, the request is thrown into a queue for processing, and the server immediately returns to the client. In the request is a unique ID for the request, and information about the callback service. When the request is finished being processed by the worker thread, the server calls the callback web service on the client with the unique ID passed in the original request and the response, so the client knows which request was processed.

The speakers then proceeded to show how the callback technique would be implemented, step by step. However, I think the main value in this presentation was the description of the technique. The implementation was pretty straight forward and easy to understand, especially if you have experience dealing with web services.

One item the speakers did caution us about was the necessity to persist the queue of requests (either to disk or database). Keeping the queue in memory is not sufficient, because all of the requests will be lost if the application crashes or is suddenly terminated.

JRuby at ThoughtWorks

This was a very interesting talk about JRuby, and how ThoughtWorks uses JRuby for both internal projects, and client projects. Thoughtworks is a consulting company that is well known for its agile methods.

Those who have worked with Ruby know that it is great for agile development because it is very readable and expressive, it leads the industry when it comes to testing innovation, and it allows for easy, quick prototyping.

But, the standard Ruby implementation has many issues. Ruby does not use native threads, which presents scheduling issues for multithread applications. It has weak Unicode support. It has poor performance; even the new version, 1.9, leaves much to be desired. The garbage collector doesn’t work that well, stopping all processing while it collects garbage. The C language extensions to the library have caused many issues, especially in the area of cross platform compatibility. It is also a challenge, politically, to get a Ruby application deployed to production environments in some companies.

JRuby addresses all of these issues. Java threading is used, which addresses all of Ruby’s threading issues. Java has full Unicode support. JRuby performs better than even the new version of Ruby (in long haul testing). The Java garbage collector is used, providing quick, reliable, and dependable garbage collection. All language extensions are written in Java instead of C, solving the portability issue. And, companies who already have a Java production environment in place usually don’t have an issue with deploying JRuby applications, since they can be packaged and deployed just like Java applications. In fact, some may not even know that they are deploying a Ruby application.

Another major strength of JRuby is the ability to fall back on Java in the case were Ruby is not a good fit, like a performance intensive part of the application, or maybe connecting to a database that does not have a Ruby adaptor.

The speaker then described some of the projects that have been going on at Thoughtworks, and demonstrated one of the web applications they user internally to manage projects.

Leave a Reply

Your email address will not be published. Required fields are marked *