Today’s best sellers in the world of business books are not like they were a decade ago. While the most influential writers had their background from magazines like The Harvard Business Review some years ago, today they’re more likely to write for The New Yorker or Wired. Writers like Malcolm Gladwell and Chris Anderson have skyrocketed as the leading thinkers in the world of business literature, and even tapped into the larger consumer market with their astute observations of the business world. Their secret is to follow the old axiom of simplifying and exaggerating rather than being too concerned with complications. I do the same with many of my talks, and just like milestone books like “The World is Flat” and “The Long Tail”, I too have been criticized for not having a balanced enough presentation of my material. This is very apparent on the ratings for my “Want SOA? Throw out your Web Services!”-talk on the ongoing MSDN Live tour. The ratings I get are very polar, most people give my talk a four or five (on a one to five scale), but quite a few give me a one. Surprisingly there are very few in-between. I’ve shaped this talk to provoke a reaction and challenge the way most people think about SOA. I also know that my full-on attack on established “best practices” for service oriented architectures is uncomfortable for those who have spent time and money building their SOAs to these principles. My question to you is do you see any return on investment?

Even if it might seem like it when I give the talk, I’m not offering a panacea for all your SOA challenges. I am however showing you a different way of thinking about service orientation than the too-tired reuse oriented layered web services model. Hopefully this gets you thinking about whether the SOA we’re used to really solved the challenges it addressed, or if we’ve been lured into a vendor trap where the solution to one technical problem just unveils two more.

I think Torbjørn nailed it in his latest Contiki Strip installment, don’t just do something because I or anybody else tells you so.

JavaZone is only one week away. This year I'll be doing a talk how we can improve our designs to achieve better separation between business and infrastructure concerns. These teasers have been leaked to YouTube a while ago, but with just one week to go, time has come to bring them to the masses.

So credit is due to Udi for the second teaser, I essentially remixed the Yoda slide from his Intentions and Interfaces talk. Udi; I'll send you the HQ version of the clip if you're keen on using it in future versions of your talk.

Looking forward to seeing (many of) you next week!

Last weekend I met with Johannes for a couple of beers at Mono. As always, our discussions got quite esoteric and one of the things we talked about was weird computer science books. If you’re anything like me, you steer away from the mass produced “Teach yourself something in 24 hours” titles and head for the ones that really stand out. In the wake of our discussion I figured I’d write up the “Anders Norås Guide to Weird Computer Science Books” so here goes.

Max Objektorienterar

First off is the Swedish classic “Max Objectorienterar”. This is a children’s book about young Max who explores the wonderful world of object oriented programming. The book has wonderful illustrations by Eva Eriksson depicting childish UML diagrams.

There is also an English translation of the book available, but this one is not as good as the original Swedish title because the names of OO concepts don’t resemble English names in the same way they do in Swedish. “Titta Arve” has the double meaning of “Look Arve (name)” and “Look, inheritance”.

(Yes. I know this is not a real book, but it is still better than most teach yourself OO titles.)

The Little Schemer

The Little Schemer by Daniel P. Friedman and Matthias Felleisen is by all means a serious computer science title, but the style of writing and the illustrations in the book are very different from what you’re used to.

I first got introduced to this wonderful book when my ex-girlfriend studied informatics for humanists at the University of Oslo. At this course they wrote little Scheme programs to learn how to think logically - something my ex really could get better at. Just like Scheme, the book is a little challenging at first, but once you get used to it you’ll be reading the lambda expressions like your ABC. Here is an example taken from the book to give you a feel of what this is about:

Are you in the mood for caviar?                  Then we must go looking for it.

What is (looking a lat)                          #t, 
    where a is caviar                             is obviously in lat.
    and 
        lat is (6 2 4 caviar 5 7 3)

(looking a lat)                                  #f
where a is caviar
and
    lat is (6 2 grits caviar 5 7 3)

Where you expecting something different?         Yes, caviar is still in lat.

True enough, but what is the first number        6.
in the lat?

And what is the sixth element of the lat?        7.

And what is the seventh element?                 3.

So looking clearly can't find caviar.            True enough.
                                                     because the third element is grits, which
                                                     doesn't even resemble caviar.

Here is looking                                  We did not expect you to know this.
  (define looking)
    (lambda (a lat)
      (keep-looking a (pick 1 lat) lat)))

Write keep looking.

Strange isn’t it? The Little Schemer is the follow up to The Little Lisper. There are also a few other interesting titles in the series, all written in the same quirky style. Here is an excerpt from “A Little Java, A Few Patterns”:

Let's define more Seasioning                     We can have lots of Seasonings
class Thyme extends Seasoning {}                 class Sage extends Seasoning {}

Quirky recursiveness topped off with lots of cute drawing of elephants and mice, or dancing coffee cups if you’re more into Java than functional programming, explaining the fundamentals of programming makes a perfect combination.

Mr. Bunny’s Big Cup O’Java

“Let me guess,” said Mr. Bunny. “This time it’s Java.”

“How did you know?” asked Farmer Jake. He wondered with a flush of embarrassment if all his predicaments were so predictable.

“Are you going to tell me Java is a new way of controlling my pixels?” asked the farmer, proudly remembering his last adventure with the bright little bunny.

Farmer Jake could still say “pixel”!

“Oh, Java is designed to control much more than your pixels.” said Mr. Bunny. “Java is a new way to control that big fertilizer company in Redwash County.”

Farmer Jake nodded thoughtfully.

“Jake makes a simple promise to the programming community.” continued the rabbit.

“That we’ll be free at last?” asked Farmer Jake.

“That you’ll never run out of work.” said Mr. Bunny. “With Java, programs can be written once, and can break on almost any platform.”

Mr. Bunny quickly sketched a diagram in the dirt.

“Wow,” said Farmer Jake. “Is it really that easy?”

“Sure”, said Mr. Bunny with a wink. “Now let’s sin a little song.”

And so Mr. Bunny began to sing, and Farmer Jake sang along, to the tune of “When You Wish Upon a Star.”

If Daniel P. Freidman’s style isn’t quite you’re cup of tea, maybe a big cup of Java is the way to go? “Mr. Bunny’s Big Cup O’Java” by Carlton Egremont is another favorite of mine.

You won’t learn a thing about Java programming from reading this book, but you’ll laugh your heart out. The illustrations used through out the book are spot-on satire on the too tired square, triangle and circle ones we see in technical books, documents or articles every day. The examples used to explain the different concepts in the language are hilarious, for instance interfaces are explained through a story of a guy who is the major, the sheriff, a painter and a load of other things at once. Coming to think of it, no other book ever has made the concept of interfaces as roles as clear as “big cuppa” does.

Mr. Bunny’s Guide to ActiveX

In Visual Basic, you form windows using forms. A form is a window that you form. At first forms are unformed. You must form your forms using the form designer (formerly the former). In the form former, an unformed form forms a uniform formation….

Mr. Bunny’s Guide to ActiveX was the first of the Mr. Bunny series, and it is even more hilarious than the Java title. It is in this book we get introduced to the most basic building block in computer software, which is referenced opening of the “Big cuppa” book (above), the pixel. Just like the other Mr. Bunny book, this is a nonsensical book on ActiveX programming filled to the rim with injokes on the technology. There are jokes on every aspect of Windows programming, and you’ll find answers to questions you never though you’d ask like “How is ActiveX diffrent from ActiveY?”. Egremont even manages to be funny about CLSIDs - pure class!

I am a Bug

Robert Sabourin’s I am a Bug is a picture book illustrated by his 12 year old daughter intended for parents in the software business who want to explain what they do to their kids. The book is focused at the quality assurance aspects of our trade, and it is just as useful when explaining QA to executives as when explaining to children.

Mommy, Why is There a Server in the House?

“When daddy loves mommy very much, he buys her a stay-at-home server.” Speaking of children’s books, we can’t forget Dr. Tom O’Connor’s excellent “Mommy, Why is There a Server in the House?”.

This book is not a real children’s book, but rather clever marketing for a Microsoft product. If you don’t feel like spending $6 on marketing material, you can always read it online at: http://www.stayathomeserver.com/book.aspx

Why’s (poignant) guide to Ruby

While I felt like I was high on some weird drug many a time whilst writing this guide, there is no book more spaced out than “Why’s (poignant) guide to Ruby.”. This one is just plain and simple ridiculously funny, with the added bonus that you might actually learn a thing or two about Ruby along the way. This book is packed with weird and wonderful drawings, photo montages and cartoons, quirky code samples and lots of humor. This is a must-read for any developer, and whether you actually care about Ruby or not doesn’t really matter.

Treat yourself and go off to read some of these titles. They are much funnier than this sad blog ever will be. Who knows, maybe you’ll learn something as well?

Quite a few .NET based Composite Oriented Programming spikes have surfaced in the wake of my humble COP spike last week. I was by no means the first to implement this concept on .NET and most of the other spikes were written long before I posted mine. As far as I know Fredrik Kalseth was first to the flag when he wrote about it back in February and he made his code available when he revisited the topic last week. Fredrik ended up in the experimental field of COP after having explored AOP by rolling his own AOP framework. Writing an AOP framework is a fun way to learn lots of things about low-level .NET stuff. I have witnessed all of the challenges with implementing Castle’s Dynamic Proxy, and I would recommend that using this rather than building your own to anyone who gets serious about building a COP framework. Henry Luk, who was the second to do COP on .NET, used Castle Dynamic Proxy and his code is very similar to what my stuff looked like before I added support for references within the composites.
Yves Goleven wrote his COP POC (look anagrams!) with .NET’s own RealProxy and like me he keeps a registry of the “traits” to support dispatching to the pieces of a composite.
The last to join the party was Magnus Mårtensson. Magnus built his “framework” on top of the Unity container and he too used the RealProxy for his proxying needs.
From what I can understand, Magnus is quite determined to go forward with writing a full fledged COP framework. Magnus works for Jayway’s sister company Dotway, and Jayway is of course where the whole Qi4j thing started so Magnus is likely to get the corporate backing needed to take on such a challenge.
There has been some speculation on whether I will get more serious about Qi#, and even if I kind of feel the urge, I won’t do it now for a couple reasons.

I already have my Quaere project which I haven’t been able to do any serious work on for a long time - my apologies to Michael Hunger for bringing that project to an abrupt stop. This was partly because of personal decisions and me not being able to use the stuff I was building in my daily work. I used bits and pieces of Quaere for forthcoming talk at JavaZone and I really want to get that show rolling again soon. I just need to find a way to make me able to be more committed than I am today.

The other reason is more interesting, even though this is more or less pure speculation. On PDC this year Anders Hejlsberg will do a breakout session on the future of C#. The last time he did this he unveiled LINQ and I suspect we have something related to COP coming.

C# 4.0 will have support for dynamic dispatch. The behavior will be similar to Visual Basic’s late binding feature and one of the key motivations for adding it is to improve interoperability with types written in dynamic languages running on the Dynamic Language Runtime. A cool side effect of having dynamic dispatch support in C# is that it will make reflective method invocations much easier to do. Rather than having to go down the tiresome road of getting a MethodInfo from a type and then invoking that method on an instance, we should be able to surround a block with the suggested dynamic keyword and do this:

dynamic
{
    object myComposite = compositeFactory.Create();
    myComposite.sayHello();
}

As with Visual Basic’s late binding, the method invocation would of course be bound to an object instance, and hence it would not be as dynamic as Boo’s IQuackFu feature or Ruby’s method_missing. Still, having this kind of dynamic dispatch support would be a step in the right direction for getting intrinsic Composite Oriented Programming support in the language.

While the dynamic keyword isn’t set in stone, dynamic dispatch is more or less a confirmed feature in C# 4.0, but there is another thing I suspect my namesake will unveil in Los Angles this October that is even more interesting…

One of the ingenious things that make LINQ work is the expression trees that are constructed at runtime. These can be inspected, altered and transformed just like the abstract syntax trees used by compilers, they can even be compiled into IL code by invoking the tree’s compile() method. When you think about it, LINQ’s expression trees is a convenient way to build IL code at runtime. This can be extended to also cater for runtime construction and compilation of other structures at runtime, and in a sense this exactly what we’re aiming at with composite oriented programming. Keeping in mind that many of the features we’ve seen in the two latest incarnations of C# are adopted from dynamic languages, I don’t think it is too far fetched to speculate that some form of dynamic object construction will be part of C#.

In combination with dynamic dispatch, such a feature would cover a most of the usage scenarios for COP. There might be some shortcomings with regard to more advanced features such as side effects, but then again C#’s event support covers partially for this.

If dynamic construction becomes part of C#, I’m not going to invest a lot of effort into building a COP framework for .NET. This is the second reason why I won’t start developing such a framework now. I might be wrong in my speculations, and if so could I would be happy to contribute to such a project as long as I’ve got my challenges with being committed to Quaere get sorted. We'll know for sure in October.

My quick and dirty Composite Oriented Programming spike seems to have gotten quite some attention around the blogosphere, so I better keep my promise and publish the source code. The source code can be downloaded from http://andersnoras.com/files/folders/code/entry595.aspx.

Please keep in mind that this thing was hacked together in about an hour, so be gentle with me when it comes to robustness.

Last year, Rickard Öberg unveiled his Qi4j project. Qi4j is a framework for domain centric development thru Composite Oriented Programming (COP). Composition of larger objects from finer grained fragments is one of the core principles of this paradigm, and Qi4j does it by piecing together mixins to form instances.
Some of you might be familiar with traits which is a very similar concept. Traits are a simple composition mechanism for structuring object oriented programs. Essentially, a trait is a behavioral building block which is the primitive unit of code reuse. Traits have been implemented in a number of programming languages, and there is even a Microsoft funded research project which explores traits as a C# feature.

Since the 3rd pre-release of Qi4j hit the streets earlier this month, the buzz around the framework has increased, and I decided to blow the dust of a small prototype I started thinking about when I last met Rickard for a couple of beers and a lot of geek-speak. I must admit that I find the idea of composing large scale behavior from tiny, specialized bits and pieces, especially because the way sound design principles force their way into ones code.
Qi4j is a full fledged framework built on the patterns described in Eric Evans’ seminal Domain Driven Design book, and if you look at demos on their site you’ll notice that many of the mechanisms in the book manifest themselves clearly in the code. My humble demo does not feature all of the Qi4j concepts, but it does show how one can do instance composition in C# with a little help from Castle Windsor.

Before digging in to the nitty-gritty details of how it actually is done, lets take a look at how we can compose some “traits” into a composite.

Since the “traits” are behavioral in nature, we begin by describing them as interfaces.

public interface IDialogSettings
{
    string Name { get; set; }
    string Phrase { get; set; }
}

public interface ISpeaker
{
    string Say();
}

Those who are familiar with Qi4j probably recognize these from the Hello World demo. The IDialogSettings describes the state part used by the composites, while the ISpeaker interface describe the ability to “say something”. The implementation for IDialogSettings is straight forward, so we can safely skip that and look at the ISpeaker implementation (which is kind of straight forward as well).

public class Speaker : ISpeaker
{
    private IDialogSettings settings;
    [This]
    public IDialogSettings Settings
    {
        get { return settings; }
        set { settings = value; }
    }

    public string Say()
    {
        return string.Format("{0} says \"{1}\".",settings.Name,settings.Phrase);
    }
}

Notice that the implementation has a dependency on IDialogSettings that is not part of the interface and that this property is marked with the mysterious This attribute. This is a marker which is used to bind to other “traits” on the same composite. More on this when we look behind the scenes. Finally we describe the composite with yet another interface;

public interface IWorldGreeter : ISpeaker, IDialogSettings {}

Composition happens at runtime, so we’ll need to register the “traits”, the composite and the Qi# facility in the container.

<castle>
  <facilities>
     <facility id="qisharp.facility"
               type="Noras.Sandbox.QiSharp.CompositeFacility" />
  </facilities>
  <components>
    <component id=”settings”
 
             service=”Noras.Sandbox.QiSharp.IDialogSettings”

              type=”Noras.Sandbox.QiSharp.DialogSettings”
 
             lifestyle=”Transient” />
    <component id=”speaker”
               service=”Noras.Sandbox.QiSharp.ISpeaker”

              type=”Noras.Sandbox.QiSharp.Speaker”
 
             lifestyle=”Transient” />
    <component id=”greeter”
 
             service=”Noras.Sandbox.QiSharp.IWorldGreeter”
               isComposite=”true” />
  </components>
</castle>

We can resolve a composite instance just like any other type;

    IWorldGreeter helloWorld = container.Resolve<IWorldGreeter>();
    helloWorld.Name = "Marvin";
    helloWorld.Phrase = "Hello World!";
    Assert.AreEqual("Marvin says \"Hello World!\".", helloWorld.Say());

As you might suspect, the instance is a proxy. Lets take a look at the component activator responsible for creating composite components.

protected override object InternalCreate(CreationContext context)
{
    ProxyGenerator gen = new ProxyGenerator();
    Type compositeInterface = context.Handler.ComponentModel.Service;
    Dictionary<Type, object> traits = new Dictionary<Type, object>();
    foreach (Type traitInterface in compositeInterface.GetInterfaces())
    {
        object traitImpl = Kernel.Resolve(traitInterface);
        if (traitImpl != null)
        {
            traits.Add(traitInterface, traitImpl);
        }
    }
    // Wire internal dependencies...
    foreach (object trait in traits.Values)
    {
        Type traitImplType = trait.GetType();
        foreach (PropertyInfo property in traitImplType.GetProperties())
        {
            if (Attribute.IsDefined(property,typeof(ThisAttribute)))
            {
                if (traits.ContainsKey(property.PropertyType))
                {
                    property.SetValue(trait,traits[property.PropertyType],null);
                }
            }
        }
    }
    object proxy = gen.CreateInterfaceProxyWithoutTarget(
                                   compositeInterface, 
                                   new CompositeInvocationInterceptor(traits));
    return proxy;
}

First we create a dictionary of “trait” instances by resolving all of the implemented interfaces from the container, then we scan these for This attributes and wire the dependencies whenever we find one, regular dependencies are resolved in a regular manner. Since constructor can’t be defined on interfaces, constructor injection is not an option within the composites - hence we fallback to property injection here.

The “traits” dictionary is then passed to the interceptor instance which will be responsible for routing the method invocations on the composite to the “traits” supporting the behaviors.

public void Intercept(IInvocation invocation)
{
     Type targetTrait = invocation.MethodInvocationTarget.DeclaringType;
      if (traits.ContainsKey(targetTrait))
      {
          invocation.ReturnValue = invocation.Method.Invoke(

                              traits[targetTrait],
                               invocation.Arguments);
      }

}

We discover which “trait” the method was invoked on by finding the type the method is declared on, then we get that “trait” from the dictionary created in the component activator. All in all it’s quite simple.

To give you a taste of how powerful composite oriented programming can be, let’s throw a little “trait” reuse into the mix.

ITeleprompter teleprompter = container.Resolve<ITeleprompter>();
teleprompter.Phrase = "Hello World";
Assert.AreEqual("Say Hello World.",teleprompter.WhatToSay);
IWorldGreeter helloWorld = container.Resolve<IWorldGreeter>();
helloWorld.Name = "Marvin";
helloWorld.Phrase = "Hello World!";
Assert.AreEqual("Marvin says \"Hello World!\".", helloWorld.Say());

In this example, the ITeleprompter and the IWorldGreeter composites share the same implementation of the IDialogSettings “trait”. To put it another way, the “trait” is reused between the two composites. Since we’re using a container here, we could also change the lifestyle of the IDialogSettings component from transient to singleton, in which case the two composites would share state.

I only spent an hour on this example, so I haven’t taken the time to implement all of the other things Qi4j sport. If you’re curious, there is quite a lot of information available at the Qi4j website.

I’ll post the code as soon as I’ve found time to clean it up.

The guys at Codehaus are moving the continuous integration servers. I must say that I had a WTF-moment when this build failure notification dropped in my inbox: I find it amusing that the build failed because “all the tests passed”. The real reason was that it was unable to find Maven on the build server…

Last week I wrote a short anecdote about getting big, upfront design wrong. The next chapter is on quick and dirty fixes. You know, those hacks we do to “make something work”. These often come about after frenetic debugging session, where we debug a system into existence. Smacking a piece of drywall on top of the existing drywall is a real-world example.

Quick and dirty fixes often have side-effects and so does this. Notice that a drawer is missing? Its because it won’t fit when the wall is 1 centimeter, or about half an inch, thicker.

Fixes like these need to be done over, taking (almost) twice as long as doing it right the first time around.

OK, I know I'm late to the party here, but I've started to upgrade from Web 1.0 to Web 2.0. I've even got myself a Twitter profile. You guys can keep an eye on what I'm wasting time on at http://twitter.com/anoras.

Before .NET 3.5 was released the choice of whether you should choose Visual Basic or C# as your programming language was more or less a matter of taste. With the first incarnations of these languages, you could do virtually the same things with both. Visual Basic 9.0 introduced quite a few new interesting features, and the support for XML literals is my favorite. For those unfamiliar with Visual Basic, XML literals allows you to work with XML DOMs using the all so familiar markup syntax. For instance you this code will build a DOM.

Dim myDOM = <SomeElement> _
                <SomeOtherElement withAnAttribute="42"> _
                    The time is <%= DateTime.Now %> _
                </SomeOtherElement> _
            </SomeElement>

Notice that you can have inline code similar to what you’re familiar with from ASP.NET. You can also use XML literals as a replacement for DOM methods to reference elements within the DOM.

Dim someDocument = XDocument.Load("somedocument.xml")
XElement someOtherElement = someDocument.<SomeElement>.<SomeOtherElement>

XML literals can be used in combination with LINQ and other Visual Basic features, and is a powerful tool when working with XML.

A couple of weeks ago I had a discussion with a team who were planning to use IBM’s Process Server and ESB to produce direct marketing campaigns from Excel documents with assorted information like customer names, addresses, key account managers and so forth. Their idea was to write an adapter for the ESB to be able to consume Excel spreadsheets as data sources, convert these into Service Data Objects and use the Process Server’s mapping abilities to transform the Excel documents into XML that can be passed on to our document production service. Can you imagine how loud my “YANGI”-scream was? This was the perfect moment to exploit Visual Basic’s XML literals to fight enterpriceyness, so I decided to spend a few hours to build a light-weight solution for this. The application accepts an Excel spreadsheet and row template, and produces an XML document with the result. The row template is written using Visual Basic’s XML literals and looks similar to this:

<Letter>
    <FirstName><%= row("First Name") %></FirstName>
    <LastName><%= row("Last Name") %></LastName>
    <HasSameLastNameAsSpouse>
        <=% IIf (row("Last Name") = row("Spouse's Last Name"),"Yes","No") %>
    </HasSameLastNameAsSpouse><
    <!-- And so on... -->
</Letter>

I took me about 45 minutes to write the application, but there was one small problem. The row templates wouldn’t compile using Visual Basic’s CodeDomProvider - even if the generated code built perfectly using the Visual Basic compiler. It turned out that the reason for this was that even when using .NET 3.5, the CodeDomProviders default to using version 2.0 of the compilers. If you’re targeting Visual Basic 9.0, you’ll have to specify this when you create a new CodeDomProvider. The MSDN documentation does not mention this at all, and the many ways of getting hold of a CodeDomProvider makes this even more confusing.

CodeDomProvider vbProvider = CodeDomProvider.CreateProvider("vb");

When you use the factory, you can only specify which language you’re targeting, so we’ll have to instantiate the provider via its constructor. The constructors for the VBCodeProvider and the CSCodeProvider accept an undocumented IDictionary as its argument. It turns out that you can pass configuration options in this dictionary. So to create a .NET 3.5 VBCodeProvider you’ll need to this:

CodeDomProvider provider = new VBCodeProvider(
    new Dictionary<string, string>{{"CompilerVersion","v3.5"}});

This is also the case if you’re looking to use the CodeDOM with C# 3.0 code. The only difference is that you’ll need to create a CSCodeProvider rather than the Visual Basic one. Below is the complete code for my super simple “template engine”.

var className = Guid.NewGuid().ToString("n");
var src = GetTemplate(className);            
CodeDomProvider provider = new VBCodeProvider(
    new Dictionary<string, string>{{"CompilerVersion","v3.5"}});
    var compilerParameters=new CompilerParameters {GenerateInMemory = true};
    var compilerResults = provider.CompileAssemblyFromSource(compilerParameters, src);
    if (compilerResults.Errors.HasErrors)
    {
        throw new CompilationException(compilerResults, src);
    }
return Activator.CreateInstance(compilerResults.CompiledAssembly.GetType(className));

Even if it is confusing, it’s still very easy to compile code using these new language features. Just remember that you’ll need to specify some magic strings to get the compiler to apply it’s magic.

Last November my family and I move into a brand new apartment. Since we’ve moved in, we’ve had builders coming in to fix things over and over again. Today they started to “refactor” the wiring in our kitchen. Maybe I should get this picture framed as a reminder of not to trust Big Design Upfront (which is the way they build stuff).

The carpenter has a rather agile aporach to his work, and he’ll be tearing down parts of the kitchen to replace the entire wall tomorrow. Luckily, I’m not paying for this.

My last post on Java generics and the Repository pattern got a bit of interest. Judging from the feedback I got, I feel the need to elaborate on the Inversion of Control part of this. As some readers pointed out, Google’s Guice container employes super type tokens to support generics to some extent. The IoC example I gave in my previous post can be implemented with Guice by binding a TypeLiteral of the interface to a concrete implementation of that interface.

public class RepositoriesModule implements Module {
   public void configure(Binder binder) {
       binder.bind(new TypeLiteral<Repository<Product>>() {}).to(ProductRepository.class);
   }
}

You can resolve an implementation of a Repository by asking the injector for an instance of the same TypeLiteral that instance is bound to.

Injector injector = Guice.createInjector(new RepositoriesModule());
Repository<Product> repository = injector.getInstance(Key.get(new TypeLiteral<Repository<Product>>() {}));

However, this does provide a solution similar to how we can inject generic repositories using something like the Windsor container for .NET. With Windsor, you can bind a generic interface, say IRepository, to a generic implementation of that interface such as ConcreteRepository : IRepository. This allows us to resolve a useable repository instance like this:

WindsorContainer container = new WindsorContainer();
IRepository<Product> repository = container.Resolve<IRepository<Product>>();

One thing to note here is that there is no need to have concrete implementations for every domain object (Product, Order, Customer and similar), a generic implementation of the ConcreteRepository is sufficient because .NET has bona fide generics implemented in the Common Language Runtime (CLR) and the CLR will create a new bound type of the generic class at runtime. This is even the case if we use reflection to create the instance.

The Guice container allows us to specify providers to which the creation of a dependency will be delegated. However, this provider is bound to the type arguments for the TypeLiteral and wild card type arguments cannot be used because the compiler is unable to infer the runtime type of such an argument. As a result we would need to bind all the TypeLiterals to different concrete implementations or different providers to support this pattern with Guice. This is a show stopper because it takes away the pattern’s flexibility. To exemplify the concept, I changed my naïve IoC container from my previous post to support this pattern using Guice’s TypeLiterals. Here is an example of binding the Repository interface to a provider which will create the typed instances via the RepositoryFactory shown in my previous post. (If you haven’t read that post, now is a good time.)

@Test
public void canRegisterAnOpenGenericInterfaceAndResolveItsImplementationViaABoundInterface()
{
    // Register the open generic interface and bind it to a provider.
    IoC.register(new TypeLiteral<Repository>() {},new Provider<Repository>() {
        @SuppressWarnings({"unchecked"})
        public Repository get(TypeLiteral<? extends Repository> type) {
            ParameterizedType pt = (ParameterizedType) type.getType();
            return RepositoryFactory.create((Class<?>) pt.getActualTypeArguments()[0]);
        }
    });
    // Resolve an instance of a bound interface.
    Repository<Order> repository = IoC.resolve(new TypeLiteral<Repository<Order>>() {});
    Assert.assertTrue(repository instanceof AbstractRepository);
    Assert.assertSame(Order.class,repository.getEntityClass());
}

In this example we first register the open generic interface, akin to IRepository<> in .NET, to a provider for that interface. The provider implementation has to perform some unchecked operations to allow this to work, but this is not really something to worry about. When we resolve the instance, we pass a fully bound TypeLiteral to the container. The provider is passed this TypeLiteral as an argument, and the type argument is extracted from it. In this example this will be a TypeLiteral>. Since the provider is bound to the open generic type Repository, the extracted type argument will be Order. This provides us with enough type information to create a strongly type instance of the AbstractRepository via the RepositoryFactory class.

We also need to be able to distinguish between generic implementations and concrete ones. So lets bring in the ProductRepository class from my previous post.

@Test
public void boundServicesHavePrecedenceOverOpenGenericServices()
{
    IoC.register(new TypeLiteral<Repository>() {},new Provider<Repository>() {
        @SuppressWarnings({"unchecked"})
        public Repository get(TypeLiteral<? extends Repository> type) {
            ParameterizedType pt = (ParameterizedType) type.getType();
            return RepositoryFactory.create((Class<?>) pt.getActualTypeArguments()[0]);
        }
    });
    IoC.register(new TypeLiteral<Repository<Product>>() {},ProductRepository.class);

    Repository<Product> repository = IoC.resolve(new TypeLiteral<Repository<Product>>() {});
    Assert.assertTrue(repository instanceof ProductRepository);
    Assert.assertSame(Product.class, repository.getEntityClass());
}

This is basically the same test case over, but with one important difference. In this example two services are registered in the container. First the provider for the open generic Repository interface is registered, and then the concrete implementation for the bound Repository is registered. When we resolve the service for TypeLiteral> we expect to get an instance of ProductRepository back, rather than a runtime generated instance of the AbstractRepository.

Below is the entire implementation of the “container” used in these tests.

public class IoC {
    static Map<TypeLiteral, Provider> registry = new HashMap<TypeLiteral, Provider>();
    public static <T> void register(TypeLiteral<T> service, Provider<T> provider) {
        registry.put(service, provider);
    }
    public static <T> void register(TypeLiteral<T> service, Class<? extends T> impl) {
        registry.put(service, new ConcreteProvider(impl));
    }
    @SuppressWarnings({"unchecked"})
    public static <T> T resolve(TypeLiteral<T> type) {
        if (registry.containsKey(type)) {
            return (T) registry.get(type).get(type);
        } else {
            Type c = type.getRawType();
            while (c != Object.class) {
                ManualTypeLiteral<T> manualTypeLiteral = new ManualTypeLiteral<T>(c);
                if (registry.containsKey(manualTypeLiteral)) {
                    return (T) registry.get(manualTypeLiteral).get(type);
                }
                c = c.getClass().getSuperclass();
            }
            throw new RuntimeException("Not found");
        }
    }
    private static class ManualTypeLiteral<T> extends TypeLiteral<T> {
        private ManualTypeLiteral(Type type) {
            super(type);
        }
    }
    private static class ConcreteProvider<T> implements Provider {
        private final Class<? extends T> impl;
        public ConcreteProvider(Class<? extends T> impl) {
            this.impl = impl;
        }
        public T get(TypeLiteral type) {
            try {
                return impl.getConstructor().newInstance();
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        }
    }
}

The implementation of the container has been simplified to make the example more clear, and is by no means a real container ready for production use. However, I think it should be fairly easy to add this kind of behavior to Guice, and I also believe that it should be well worth while because this kind of flexiblity opens the doors for a whole lot of usage patterns that we are just starting to understand the power of within the .NET community.

Whenever I stray off the beaten path of Java generics, I instantly miss C#’s generics implementation. Earlier today, Java’s type erasure erased a few good hours of productivity whilst I was doing a spike on bringing the IRepository<T> experience to Java. In C# you can get the class of any generic type argument in a straight forward manner.

public void DoStuff(T thing) 
{    
    Type thingsType = typeof(T);
}

Because of Java’s type erasure, things aren’t as simple. The Java equivalent of this C# example won’t compile.

public <T> void doStuff(T thing) {
    Class thingsType = T.class;
}

Still, all is not lost. Even if you’ve been told otherwise, some information about generic type arguments is available at runtime. While the JVM doesn’t track the type arguments for an instance of a generic class, it actually does this for subclasses of that generic class. To work around this limitation you can add the required behavior to infer a class’ type arguments to an abstract base class. Ian Robertson has a good write up about this at Artima.Since many of the features of any repository are common, regardless of its final implementation, my initial design already had an abstract repository class and a repository interface, so using the “extend and infer” technique described in Ian’s post was OK. Basically, this allows you to do this:

public abstract class AbstractRepository<T> implements Repository<T> {
    private Class entityClass;
    public final Class getEntityClass() {
        if (entityClass == null) {
            ReflectionHelper reflectionHelper = new ReflectionHelper();
            entityClass = reflectionHelper.getTypeArguments(
                            AbstractRepository.class,getClass()
                          ).get(0);
        }
        return entityClass;
    }
    void setEntityClass(Class entityClass) {
        this.entityClass = entityClass;
    }
    // Implementations of common repository features like
    // load, save, delete and so on go here...
}

public class ProductRepository extends AbstractRepository<Product> {}

Since ProductRepository specifically extends the AbstractRepository, the type information will be available at runtime and the following test will pass.

Repository<Product> repository = new ProductRepository();
Class inferredEntityClass = repository.getEntityClass();
Assert.assertSame(Product.class,inferredEntityClass);

But apart form implementing an abstract class, the ProductRepository serves no real purpose. In a real-life scenario, you would probably add some operations specific to Product entities to the repository, but there is no need to do this. So, I’d really like to have a way to create instances of a repository for any entity without creating a separate implementation of the repository for each entity class.Because of the trick we’re using to infer type arguments, we cannot turn the AbstractRepository into a concrete class, but we can extend it with a concrete generic class.

public class ConcreteRepository<T> extends AbstractRepository<T> {  }

Ayende uses this approach to support different object relational mappers in his implementation of this pattern for .NET. However, if we try to use this approach with Java, type erasure comes in and screw things up again.

Repository<Product> repository = new ConcreteRepository<Product>();
Class inferredEntityClass = repository.getEntityClass();
// This assertion fails because the type argument (Product) has been
// erased and replaced with java.lang.Object...
Assert.assertSame(Product.class,inferredEntityClass);

To work around this, we can stick with our abstract repository and employ Neil Gafter’s “gadget” aka Super Type Tokens.

Repository<Product> repository = new AbstractRepository<Product>() {};
// Did you notice this method in the AbstractRepository<T> class?
repository.setEntityClass(Product.class);
Class inferredEntityClass = repository.getEntityClass();
Assert.assertSame(Product.class,inferredEntityClass);

This works, but it makes the client code ugly. So you probably should cover the ugliness with some factory “makeup”.

public static <T> Repository<T> create(Class<? extends T> entityClass) {
    AbstractRepository<T> repository = new AbstractRepository<T>() {};
    repository.setEntityClass(entityClass);
    return repository;
}

Now we can instantiate generic repositories this way…

Repository<Product> repository = RepositoryFactory.create(Product.class);
Class inferredEntityClass = repository.getEntityClass();
Assert.assertSame(Product.class,inferredEntityClass);

…and IMHO, that looks quite alright.

Having a good implementation of a generic repository in place opens the doors to creating adaptive domain models using the patterns and design techniques Ayende and Udi have been writing quite a lot about lately. The missing piece to the puzzle is better generics support from the dependency injection containers available for Java. I’m a bit surprised that there aren’t (AFIK) any containers available that support generics in a similar fashion to what Spring.NET or Windsor do. To get this piece in place, I actually started something I promised myself that I’d never do again - I started to build my own inversion of control framework. Nothing is ready to be made public yet, but I’ll provide you with some examples of its very limited features.You can register components by specifying its interface and implementation like this (No XML configuration for me, baby!)…

IoC.register(Repository.class, ProductRepository.class);

…and you can resolve a dependency at a later stage by specifying the interface and its generic type argument(s).

Repository<Product> repository = IoC.resolve(Repository.class,Product.class);
Assert.assertTrue(repository instanceof ProductRepository);

Before you start screaming about the static methods, I’ll inform you that the IoC class is just an accessor that makes the IoC framework readily available. This is an approach I’ve been using for quite some time, and I recommend trying it for yourself. Its very convenient.

So what do you guys think? Do we need another dependency injection framework? (No worries, I’m just doing this to support some demo code I’m writing and I have no intentions making it a fully fledged framework at the time being.)

One of the challenges I have experienced when giving talks or blogging about domain specific languages is that developers are a little reluctant to writing code in languages they are unfamiliar with. This holds true even if the DSL in question is an external DSL based on commonly available languages such as Boo, Ruby, Groovy or Scala.

Since I also develop using both .NET and Java, another common challenge is that these languages aren’t generally available on all platforms. This is a concern because you can easily lock your self to a platform based on how you choose to implement your DSLs. After having many discussions around this topic with luminaries in both the Java and .NET communities, I have concluded that unless we can address the challenges with making our DSLs true cross platform tools, we are introducing more complexity than we’re doing good.

One of the reasons I’ve been a bit quite for the last few weeks is that I’ve started a new project which will be available under the Apache 2.0 license to address these issues and I’m very glad to introduce the Adaptive Platform Runtime for Interoperable DSLs – April!

To enable true interoperability and at the same time make it easy to understand for all developers April is based on familiar XML concepts. Below is an example of one of the business rule example from my recent talks on external DSLs expressed with April.

One key thing to notice is that April uses its own XSD based type system. This allows us to achieve platform portability and interoperability by abstracting away the individual languages own type systems. To allow customized DSLs, April also lets you redefine and extend the language using common XML representations. This is how the “When” keyword has been introduced into the language used above:

 <keyword>
  <name>when</name>
  <is_alias_for>
    <keyword>
      <name>
        <xmlns>urn:apl/core/language/keywords/conditional/if</xmlns>
      </name>
    </keyword>
  </is_alias_for>
  <semantics>
    <ast>
      <keyword>
        <name>when</name>
        <expression>
          <consisting_of>
            <parts>
              <part>
                <order>0</order>
                <expression>
                  <allow_any>true</allow_any>
                </expression>
              </part>
              <part>
                <order>1</order>
                <operators>
                  <operator>
                    <name>
                      <xmlns>urn:apl/core/language/operator/equals</xmlns>
                    </name>
                  </operator>
                  <operator>
                    <name>
                      <xmlns>urn:apl/core/language/operator/greater_than</xmlns>
                    </name>
                  </operator>
                  <operator>
                    <name>
                      <xmlns>urn:apl/core/language/operator/less_than</xmlns>
                    </name>
                  </operator>
                </operators>
              </part>
              <part>
                <order>2</order>
                <expression>
                  <allow_any>true</allow_any>
                </expression>
              </part>
            </parts>
          </consisting_of>
        </expression>
      </keyword>
      <keyword>
        <name>then</name>
        <!-- Eluded for brevety -->
      </keyword>
    </ast>
  </semantics>
</keyword>


Since everything is XML based you can use your experiences from writing everything form web.config files to Spring configurations to extend, customize and develop using April.

April’s core audience is the domain experts who’ll use the DSLs you develop to customize the business rules of any April enabled application. To reduce the probability of bugs occurring within these DSLs, you can easily turn of language features in the DSL context configuration.

 <dsl_context>
  <language_features>
    <keyword>
      <name>new</name>
      <enabled>false</enabled>
    </keyword>
    <keyword>
      <name>print</name>
      <enabled>true</enabled>
    </keyword>
    <keyword>
      <name>for</name>
      <enabled>false</enabled>
    </keyword>
  </language_features>
</dsl_context>

Because of its simplicity and the use of common XML knowledge, my vision is that April will be the killer app that will enable developers to DSL enabling their applications today.

The source code will be made available at The Codehaus later today. I encourage everyone interested in DSLs to start playing around with it, provide feedback or join the project. Let the DSL revolution begin!

I’m not sure if its because Java developers have a flurry of good IDEs to choose from, but IDE pimping is a rare hobby among Java developers. However, since I’m a polyglot developing stuff in a range of languages I enjoy having a familiar, nice look and feel across all the tools I use. When I swapped my Windows for a Mac, I instantly fell in love with TextMate’s celebrated Vibrant Ink theme. (Fun fact: This blog post is written in TextMate, using Vibrant Ink). I use John Lam’s port of the theme with Visual Studio, but whenever I wrote Java code I was left out in the cold with IntelliJ IDEAs plain old black, blue, red and green on white theme. As you can imagine, this was unbearable for someone used to using tricked out OSes and development tools, so I had to create a port myself.

Volia! Here is the Vibrant Ink theme for IDEA in glorious technicolor. The above screenshot showcases the various features, and (luckily) regular code seldom gets this colorful.

If you fancy pimping your IDEA with a touch of cool, you can grab a jar file with my color scheme from “Is your IDE Hot or Not?” or directly from here.

Gansta! Yo’ve gots ta git this themizzle, it tha real shiznits.
Snoop Doggy Dog