Overriding common bindings with test bindings in Jukito

This post is about how to get common bindings for Jukito tests without having to write too much boilerplate. (Obviously not a general interest post!)

A recent conversation on the Jukito newsgroup discusses various proposals for reducing the amount of boilerplate involved in setting up common bindings for tests that have a common superclass. I've noticed that the underlying assumption to these proposals is that bindings in modules are inheritable in the same way that methods are, but that's not generally the case. You can override methods by defining a new version in a subclass, but to override the bindings in a module, you need to use Modules.override, which doesn't work via inheritance.

I've written a template to illustrate how to override with test bindings; it uses Jukito 1.1 as is:

http://pastebin.com/BLQnMEqx

The key is to declare a static method in a common test superclass that returns a single module, which is easy to do with Modules.combine. Then in the concrete test class, use

  Modules.override(commonBindings).with(testBindings)

This strikes what I think is the right balance between compactness and clarity: You have one place in the concrete test class that says what the basic bindings are (commonBindings) and what test bindings are being used to override for the purposes of this test (testBindings). There's no hunting around through the inheritance hierarchy for modules with the right characteristics.

Because the Modules.combine/override approach is so simple, the case for adding special Jukito support (based on inheritance alone, annotations alone, or on a combination of inheritance and annotations) for auto-installing commonly-used modules becomes much weaker. Jukito is already pretty magical; it doesn't need to add mystery to its magic.

Java Standards Annoyances

The Java Standards Annoyances session at OSCON 2011 looks like fun. I wish I could be there.

If I were there, after first expressing congratulations mixed with condolences to Ben Evans and the London Java Community on the election to the EC, I'd probably say that the most important part of building standards is knowing when and what not to standardize. The PMO measures success quantitatively, in terms of numbers of JSR stage transitions, but the inevitable result has been that a lot of the JSRs that made it to final release are junk that should never have been accepted in the first place. The EC actually did one useful thing during my time as a member: It rejected the PFD of a (well-intentioned) JSR that was not ready for prime time.

So talk of "streamlining" the process makes me nervous. I wouldn't want to make it easier to introduce garbage, and I don't trust the EC to be a responsible gatekeeper, nor do I trust the JCP as a whole to provide high-quality feedback during public review; there's too much noise, and it's too easy for a spec lead to ignore substantial criticism.

There are good JSRs. Naturally I think the JSRs on whose EGs I have served are good ones, the most recent being JSR 334 ("Coin"). But I think the enthusiasm and energy of the community should be directed more at building great libraries and frameworks than at getting them accepted as standards.