Spring Framework and Code Obscurity

I just realized why what I don't like about Spring Framework.

Don't get me wrong. I love Spring Framework. I use it daily. In fact, I am a huge fan of it. But there is a constant "something is wrong" buzz in the corner of my mind. And I finally caught it.

The name is Obscurity

Yes, all the Spring annotation fairy dust magic just works. It is great. It removes boilerplate code. It is supposed to make your code easier to read and maintain. And it does - to a point when it doesn't.

A simple example:

@Scheduled(fixedDelayString="${execution.delay_ms}")
  public void scheduledJob(){
    // your code goes here
}

Easy, right? A few lines of code, a configurable property to define a delay between runs, what can be more simple?

A few questions:

How do you know what threadpool this scheduled job used? How do you to configure the threadpool? How do you test the scheduling part of your code? Ouch, painful!


Yes, all these questions can be answered, but you'll need to dig through the documentation and come up with a (relatively) slow integration test. But that is unnecessary complicates your life.

Fortunately, you don't have to use Spring like this. You can still use it in a good way that doesn't make you cry when you debug an issue at 2:30am.

Let's refactor the example above:

@PostConstruct
public void schedule() {
    // assume that taskScheduler and archaiusDelayProperty are autowired
    taskScheduler.scheduleWithFixedDelay(
        this::scheduledJob,
        archaiusDelayProperty.get());
}

public void scheduledJob(){
    // your code goes here
}

Someone may cry: "Oh, no! Boilerplate code!" I beg to differ - this code is so much easier to test and debug. It actually carries semantic value:

• you can see where the sheduler and the delay value are coming from,
• you can easily mock out the collaborators in your tests - so you can test the edge cases properly (e.g., what happens when the threadpool is depleted?),
• if something goes wrong, it is so much easier to have an investigation path like "Oh, this is the scheduler, let's see what threadpool it uses, oh wait, what are the settings? No way, we need to fix that." than "Okay, I have this annotation, where is the documentation that describes the effect of this annotation? Is it this one? Is this annotation affected by other settings? Where do I read about them?" The latter path sounds much harder and more obscure to me.

Finally, I need to admit - there are times when you want to use the Spring annotation magic. And some of the use cases are pretty legit. My thought is: when you use it, you should fully understand the effect - which might be not so easy. But the choice, of course, is up to you.