Much of the time for Resin 4.0 that we’re spending is in improving the underlying quality in the core Resin services. Most of these aren’t visible features, but do improve the reliability and testability of the underlying code.

Since Resin is a 12 year-old product, we need to balance the need to improve and learn from experience with the fact of a large, existing code base with a large customer base, and have found continual refactoring combined with a solid regression suite to be an effective development path.

In the case of the networking code, we’ve gone from the simple request/response of HTTP to supporting Comet/Async for the Java EE Web Profile, and prototyping WebSockets for the upcoming HTML 5.

The main networking code change was remodularization: removing all HTTP dependencies and making the networking a standalone module independent of the rest of Resin.

There are two main quality benefits of the change. By removing distractions, we can focus on exactly the networking code and nothing extraneous, making it easier to see bugs and review code. And by cleanly encapsulating the interfaces, we can verify that our testing is complete, because the quality is more dependent on the quality of our tests than the code itself.

For me the key feature of JDK 7 is the new “module” scope for classes and methods because it will finally let us distinguish between classes we want to export from internal classes that need visibility across our internal packages.

A class defined as “module class” would be internal to Resin but available to all Resin classes unlike package-private, which constrains our internal organization.

Since we can’t use JDK 7 yet, I’ve created a @Module annotation to mark the Resin-internal classes, even though they’re still declared as “public”. If we get time, we might update the JavaDoc to skip @Module tags, cutting down the clutter of non-public classes exposed as public due to the current JDK’s limitations.