Alt / is the “I’m feeling lucky” version of Ctrl Space. Instead of listing suggestions, it takes its best guess.

[via: Tor Norbye and Cédric Beust]

Weight: 4.700kg (+ 1.05kg)
Height: 53.5cm (+2cm)

Unfortunately, I arrived really late and missed the big announcement: closures in Java 7! Rejoice! (or not)

Below is a summary of what I did get to see.

The Java EE 6 Platform by Antonio Goncalves

A laundry list presentation of the new concepts, new specs and additions to existing specs in JEE 6. It’s funny how “new” actually means “stuff that implementations (Hibernate, JSF libraries, etc.) have gotten right and that we’re importing.”

Apparently, the full JEE 6 spec contains 28 other specs and is 8000 pages long! As Alex astutely pointed out to me afterwards, this essentially prevents new players from entering a market which has been reduced to roughly 3 vendors (Weblogic/Oracle Server/GlassFish, WebSphere & JBoss).

That’s where the Web Profile comes to the rescue: a spec stripped down to the stuff that 80% of web apps actually use. A lightweight server implementing it would be nice.

The fact that EJB 3.1 (a.k.a. EJB Lite) can run in a JSE environment and a few sweet new annotations (@Asynchronous, @Inject) make the EJB component model a lot more attractive than was, even in 3.0.

If you speak french and want to hear more of Antonio, you should listen to the excellent Les CastCodeurs podcast and its all-star line-up.

Writing Asynchronous Web application (Comet) using the Atmosphere Framework by Jean-Francois Arcand and Paul Sandoz

Atmosphere is framework that hides the ugliness of hand-coded server-side AJAX push and the bizarre workarounds necessary to get it to work in all browsers. For example, in WebKit, they must initially return lots of “<!– —————————– –!>”. As I said, bizarre. Atmosphere also abstracts away server-specific implementations.

Not much to say about this presentation, as it really was an introduction to the framework, but it looked very clean and simple and played nicely with JAX-RS, which is a very good API.

Distributed Programming the Google Way by Gregor Hohpe

This session divided into two parts: a brief presentation of some of Google’s infrastructure (Google File System, BigTable, MapReduce and Sawzall) and a discussion of the higher-level “Underlying Considerations” that drive their implementation. These were:

1. Sharding.
2. Less is more. Give up some features to gain others. e.g. BigTable abandons many fundamental features of relational databases to gain distribution and scalability.
3. Expect failure. Failure will happen, all the more frequently when running on vast clusters of commodity hardware. Coping mechanisms include replication, re-starting and even accepting certain forms of data loss.
4. Autonomy. Individual components should be able to survive the failure of a node by carrying on with the information they were able to retrieve. In GFS, clients look up chunk servers through a “master,” but read directly from the chunk server so that they can function even if the master subsequently fails.
5. Empower the runtime.
6. Favour Stateless.
7. Separate stateless from stateful. Three related points. Higher-level, functional, declarative programming gives the runtime more freedom to optimise, parallelise, etc. Carefully decomposing and bounding stateful contexts from stateless ones has similar benefits. In general, this means separating data gathering and aggregation (stateful) from data processing (stateless).
8. Precision vs. speed. You can’t always have both, so know when you need one or the other.

While these points aren’t really new, it’s always interesting to hear about the kinds of architectural trade-offs you have to engage in at a certain scale.

Fantom on the JVM (BOF) by Dror Bereznitsky, Frederic Simon and uncredited English guy

You may be wondering what “Fantom” is. It’s The Language Formerly Known As Fan. Although not quite as hyped as Scala, I feel Java -> Fantom is, from a language point of view, a much easier transition than Java -> Scala. Fantom seems to try to solve a lot of everyday problems developers have, in a fairly simple language with a relatively low learning curve.

I’d looked at Fan(tom) before and nodded appreciatively, but  this whirlwind tour of its features boosted my desire to really dig into it. Some of the things I really like are the native JavaScript compiler, null-safe types, optional dynamic typing, the build system and, of course, the functional aspects. The time literals for hours, minutes, nanoseconds, etc. seem a little arbitrary and weird; I just hope the Fantom approach won’t lead to too many warts.

They’re getting close to a 1.0 release, maybe adoption will start then.

In summary:

1. Application code uses the two interfaces and delegates the object-to-XML-and-back (or OXM) work to them.
2. The application context is configured to use Spring’s wrapper around an OXM framework.
3. The wrapper is injected into the bean.
4. The OXM framework also needs to be added to the classpath and configured.

To me, there are two levels of indirection too many here, already. Add another level if the application wraps this up in an XmlService interface and corresponding implementation.

Furthermore, it turns out that the abstraction is leaky! From the Spring WS docs:

Although the marshal method accepts a plain object as its first parameter, most Marshaller implementations cannot handle arbitrary objects. Instead, an object class must be mapped in a mapping file, registered with the marshaller, or have a common base class. Refer to the further sections in this chapter to determine how your O/X technology of choice manages this.

Despite all that indirection, you still need to know which OXM is being used. If you have to know what you’re using, why not work more directly with the OXM and avoid the decoupling theater?

I would go so far as to argue that, not only is the indirection not buying you anything, it’s probably going to end up costing you, by making the application’s wiring more difficult to understand and maintain.

I’ve been working with Guice of late. Its focus on programmatic configuration encourages you to  ”touch” 3rd-party APIs directly. This feels lean and natural compared to Spring’s often unnecessary infinite indirection.

Apply DAO design to XML and you’ll find that a few simple methods are enough to decouple you from your OXM in the same way a DAO decouples your from your ORM. For example:

void save(Object entity) // serialises to XML
<T> T get(Class<T> myClass, String xml) /* converts from XML to object of type T
Replace String with File or InputStream as needed */

Even if for some bizarre reason you need two OXM frameworks at the same time, the XML DAO should be injected with both OXM classes and decide which one to use based on the class of the object passed into the save() method.

To be really fancy, apply the Interface Segregation Principle (PDF): have the XML DAO implement two interfaces and let clients choose the one they’re interested in. These might be drawn from the problem domain (UserXmlDao, ArticleXmlDao) or the solution domain (CastorXmlDao, JaxbXmlDao) [1].

In conclusion: indirection has advantages, but it also has a cost. Using it indiscriminately for trivial things leads to accidental complexity and confusion through over-engineering.

[1] See Tim Ottinger’s paper on variable naming for the concept of problem and solution domains.

The advantage is that you’re doing state-based rather than interaction-based testing and the assertions are fairly readable (and would be even more so with FEST-Assert).