IOC without an IOC-container

Spring is my framework of choice if I need to write enterprise applications. But in some occasions using Spring (or more dressed down IOC containers) is not an option, because:

  1. it is too heavy/big. In some (rare) cases every byte counts
  2. you can’t introduce new dependencies.
  3. all kinds of political reasons

A practical example of such an strange application is a javaagent. I’m working on one for the ‘Concurrency Detector’ and javaagents typically are small. And introducing extra dependencies can introduce unforeseen side-effects, e.g. I had a problem with using AspectJ in my Javaagent in combination with AspectJ in a webapplication. The side effect was that my class transformations totally got bypassed. That is one of the main why I dropped AspectJ for the concurrency detector and decided to use ASM instead.

So what if you can’t use an IOC container, but do want to use IOC. Simple: just create one (perhaps more) class that glues all components together, just like in the Spring container. This class can know of all specific implementations, policies/strategies, initializations etc etc. All the stuff you normally do in a Spring container you can do in this class. The components of your system don’t need to be aware of the IOC-container they are running in, and that is how I like my OO design.

3 Responses to IOC without an IOC-container

  1. It is completely wrong of you to say that spring is a heavy framework.It is considered as one of the lightest framework and this has been one of the main reason for its success.As far as AspectJ, it has been around for long and is a very stable framework for AOP.

  2. pveentjer says:

    Thank you for replying.

    Like everything, it depends on the situation.

    Spring can be used in most standalone/web/backend application. But there are exceptions like I explained in my post. I’m currently working on various java agents and making use of Spring in these situations could be a bad choice (it bloats the agent, could lead to strange conflicts when the agent is using spring, but also instrumenting a spring application).

    And AspectJ is a mature technology, but it doesn’t mean it is the best solution for what I need (low level byte code instrumentation). ASM gives me much more flexibility. And one my agents based on AspectJ didn’t work nice with AspectJ based Spring applications (my configuration was bypassed completely as soon as the Spring AspectJ stuff got loaded). So this was one of the many reasons to drop AspectJ and use a more low level bytecode manipulation library.

    So it doesn’t make AspectJ or Spring a bad product, only a bad choice for this situation.

  3. Muru says:

    I am also in a similar situation where i dont find it suitable of using any containers.
    I am planning to use IOC in my design but i dont have to use any IOC containers like spring.So how do i go about developing my own IOC conatiner ?

Leave a comment