JetBrains’ Dmitry Jemerov on Scala
I can rave about JetBrains' IntelliJ IDEA until the cows come home - it is simply a superbly executed and very well focused product. What I found especially interesting is the following quote on Scala becoming a dominant language for the JVM:
I don't believe that, however: Scala is very complicated, it's tricky, and has a lot of surprises and edge-cases. I would say that Scala is at least as complicated as C++, and with C++ you need a hundred-page style guide before you even start writing C++ code, otherwise you'll end up writing C++ code that nobody will understand.
Scala gives an impression of great elegance and simplicity at first glance but the same goes for Perl as well. The one feature of Scala I really like is the language-level support for traits which allow reusing multiple concrete implementations similarly to multiple inheritance, but with fewer gotchas.
Via Artima: JetBrains' Dmitry Jemerov on IntelliJ 8, Flex, and Scala.
Uncle Bob’s upcoming book: Clean Code
Awesome - finally something to bash people on the head with when they write ugly code! 
(Ok, the "code smells" from Refactoring are a good start too but this seems more pedagogic in nature.) There are a lot of technical books out there, but few focus on good general practices. One of my favourites is Effective Java by Joshua Bloch, but it's focus is slightly more architectural and less on day-to-day coding. I love Bob Martin's writing so I didn't have to look long at the table of contents to order my copy as soon as it's available!
Load balancing with Spring AOP
As we all know, AOP lets you insert arbitrary code at pre-defined program boundaries - like just before method calls for example. One cool side-effect is that you can decide to not make the call at all, or to call a different method instead. Spring's AOP framework recognizes that not all calls will necessarily route to the same target object, and provides the TargetSource interface which can be used in conjunction with dynamic proxies to supply objects on demand, as calls happen. The following is a rather trivial round-robin load balancing that demonstrates how we can distribute the load over any number of Java objects transparently to callers and callees.
Download: Source code including unit tests and examples.
Some ideas for improvement:
- ability to integrate with Commons Pool (for non-reentrant objects) in place of the simple list currently used (extend AbstractPoolingTargetSource?)
- add an interceptor to detect a configurable list of exceptions and automatically remove bad objects from pool
- ability to re-create beans from a prototype definition in the bean factory as needed (similar to the existing PrototypeTargetSource)
Making Spring’s JaxRpcPortClientInterceptor recover from Axis failures
UPDATE 10 July 2008: This issue has been resolved in Spring 2.0.3 and later by introducing a "refreshServiceAfterConnectFailure" property. Unless you are stuck with an older version of Spring, do not use the solution offered below.
The Spring framework includes a very handy class in the form of JaxRpcPortClientInterceptor as part of the Remoting package. This class allows you to treat web services just like any other dependency - configure, create and inject them in your application context XML file. This is quite clever in that you can write code that works against a Java interface and doesn't care about the underlying remoting protocol used.
The JaxRpcPortClientInterceptor class has a "lookupServiceOnStartup" property which lets you defer the WSDL fetching and initialization until the first request is made. This can help you if the server hosting the web service is not up at the time when the port interceptor is being initialized, however it doesn't help if the web service host disappears afterwards or does not become available until after a call is made. It would appear that Apache Axis (which is the actual JAX-RPC implementation used) gets confused quite easily by network failures and so it helps if you re-create the JaxRpcPortClientInterceptor whenever such a failure is detected. However, if you wanted to keep the benefits of IoC, handling these failures could result in a complicated tangle of BeanFactoryAware factories and exception handling code - not exactly what we want after we've seen just how elegant SOAP access can be with a little Spring magic. I found that in some cases I had to redeploy my application after the web service host disappeared for a short period of time - this is unacceptable in a production environment.
The following code uses Spring's own AOP framework to implement a form of failure recovery completely transparently to existing code. This demonstrates the combined power of IoC and AOP quite well - they allow us to modify behaviour without touching the existing code which was not explicitly designed for pure OOP extensibility (see the Open-Closed Principle about that).
The following XML fragment demonstrates the "pure Spring" approach to configuring web service access using Axis:
And here is the reworked example which makes use of the custom TargetSource:
Source code: