Globally configurable wiring alternatives in CDI

The problem

Among the shortcomings of CDI (1.0) as a general purpose DI container is the lack of what Spring 3.+ users know as profiles (not to mention Guice, which is much more expressive due to its Java EDSL approach). The CDI feature which looks closest at a first glance is the concept of alternatives, quickly turns out to be utterly useless: You can annotate your beans directly (or indirectly, via stereotypes) as @Alternatives and then choose among them for one bean-archive (read "jar") only by selecting them in the META-INF/beans.xml file.  So, there is no way to switch between wiring-profiles without repackaging (possibly all) the jars in the deployment-unit. CDI 1.1 improves very slightly on this by allowing a "global" selection in only one of the "beans.xml" which is still far below par.

The implementation-selector pattern

My currently favored work-around consists of the following steps

• define an enumeration of profiles
• define a qualifier annotation referring to one of those profiles
• annotate service alternatives with the above profile-qualifier
• define a producer selecting the appropriate profile programmatically, publishing it to "@Default" injection points.

In some more detail:

Profile enum and annotation

Let's start with the annotation: The Enum's slightly more interesting, because it sports a reference to an annotation literal which comes in handy later, when we select the right instance:

Annotate your service alternatives

Now we can annotate our service alternatives like

@InProfile(IN_MEMORY_DB) public class SampleSvcForInMemoryDb implements SampleSvc { ...

Define the implementation-selector

This is just a bean containing a producer method like this: Thanks to the @Any annotation, it gets all available instances injected. It then selects the appropriate one for the activeProfile, which is a member variable in this sample, but can, of course be any method-call. Unfortunately, CDI does not allow a useful generification of that pattern, as far as I could see. It's still inferior to what other frameworks offer, but if CDI is a set standard, it's usable.

Autocompletion support for Scala's combinator parsers

Recently, I came to revisit Scala a bit more in depth -- compared to the odd script or hack I did before. Now, things at work change a bit: some green-field stuff to be done, even calling for some kind of DSL -- ok, maybe not really calling, really loudly but close enough to warrant spending some quality playing-time with my favorite "next great programming language".
So I threw together some combinator parsers which was some fun in itself and most of it felt very good. Except there was no autocompletion. The envisioned DSL should, among other things, navigate a mildly complex domain model. But, in contrast to a generic expression language, typos in property-names should be caught at the syntax level, and possible completions should be displayed when the user types the start of a property (or a dot). What I wanted to do was something like the made-up example below:
Of course, in the real DSL, the properties would not be hardcoded but reflectively collected from the model. The missing key-feature here is the CompletingParser mix-in: It doesn't come with the standard Scala library and I didn't easily find a nice solution readymade. So, that looked like a good opportunity to take Scala's extensibility for a test-drive that's both, interesting and easily within a Scala-beginner's reach
The basic ideas are

• override the Parser class' alternative combinator "|" to make it collect possible completions in the ParseResult instead of just returning a Failure
• override the implicit factory method for string literals to produce an alternative literal parser which differentiates between an unexpected and a missing character

As it turns out, in the standard implementation, the | combinator just delegates to ParseResult's append method which normally discards all results but the successful one, or, failing that, returns the failure which consumed most of the input stream. So we just need to replace the Failure parse result with a version that's able to keep track of possible completions, rather smellily named MissingCompletionOrFailure. This plan led me to the following little trait:
Now a simple command-loop to take our work for an interactive test-drive looks like this:

Pleasant surprise: JUnit supports Design by Contract

I've long felt contract envy of languages like Eiffel supporting Design by Contract. Only recently, I stumbled over the (not so) recent addition of theories to JUnit. Once the object instances under test are separated from the test-code - now taking on the form of a logical implication, making the latter re-usable is the obvious next step. Ever been tired of writing tests for your value-object's equals and hashCode methods? Try this:

/**
 * Provides JUnit theories that check, whether an arbitrary class 
 * satisfies the Object interface contract regarding the methods 
 * equals and hashCode. Instances of the class(es) to be tested 
 * have to be provided in derived classes 
 * 
 * @author scm
 */
@RunWith(Theories.class)
public abstract class ObjectContractTheory {
    
    @DataPoint
    public static final Object INSTANCE_OF_UNRELATED_TYPE = new String();
    
    @Theory
    public void equality_is_symmetrical( Object o1, Object o2) {
        assumeThat( o1, equalTo( o2 ) );

        assertThat( o2, equalTo( o1 ) );
    }

    @Theory
    public void equality_implies_equal_hashCodes( Object o1, Object o2) {
        assumeThat( o2, notNullValue() );
        assumeThat( o1, equalTo( o2 ) );

        assertThat( o1.hashCode(), is( equalTo( o2.hashCode() ) ) );
    }
        
    @Theory
    public void identity_implies_equality( Object o1, Object o2 ) {
        assumeThat( o1, sameInstance( o2 ) );

        assertThat( o1, equalTo( o2 ) );
    }

    @Theory
    public void any_object_is_unequal_to_null( Object o1 ) {
        assumeThat( o1, notNullValue() );
        
        assertThat( o1, not(  equalTo( null ) ) );
    }

    @Theory
    public void unrelated_classes_are_not_equal( Object o1, Object o2 ) {
        assumeThat( o1, notNullValue() );
        assumeThat( o2, notNullValue() );
        assumeThat( o1,  not( instanceOf( o2.getClass() ) ) );
        assumeThat( o2,  not( instanceOf( o1.getClass() ) ) );
        
        assertThat( o1, not( equalTo( o2 ) ) );
    }


}

Then to make sure that Integer fulfills that part of the object contract, you would simply write:

public class ObjectContractTest extends ComparableContractTheory {    
    @DataPoints
    public static final Integer[] INTS = {1,2,3,4};
}

Which is hardly to much to ask, even if creating your really interesting objects were slightly more verbose.