A Quick Look at Spring Batch
If you‘ve looked at one Spring project, you‘ve seen them all. They have a huge document on how to use Batch, but as you slog through it, it‘s the usual Spring ‘architecture,‘ which is basically super vanilla, painfully procedural, and based on the idea of leaving you a bazillion little crags to climb on. The problem with that approach to framework design is it leads straight to Microsoft Access land. You know, you make something moderately complex, and when you come back to it, you spend hours mumbling to yourself ‘maybe it was in the onnext from panel y or on start on task x…?‘ There is no logic, no real model, just a bunch of little snippets and doohickeys adorning the magnificent glory that is the tool itself.
At one point, in the docs, they roll out what they call ‘The Delegate Pattern.‘ Ok, specious use of the word pattern is a misdemeanor in these parts (an immediate Soupy Sales Award for that). There is no pattern there. I think the authors started realizing that 30 pages of block quoted xml examples was making their audience think teething was the only stage they would pass through in using the product. Seriously, are we still doing little snippets of xml bean definitions to build things?
Finally, about the actual framework and design. Even on the naming side, the choices are pretty lame. There‘s a Job and there‘s a JobInstance. This is a classic naming problem, but I like to go in the other direction: I would call the actual thing running Job. The idea here is clearly a simple example of the Prototype pattern. You could hold a Job instance somewhere as the current template or you could make a class called JobTemplate or JobDefinition, and then when the time comes, you would clone that object. There are a ton of legitimate design patterns that could come up in doing a Job engine: Command, Strategy, State (for the job itself), Composite (tasks that include other tasks), etc. None of those show up. Basically, you have a plethora of basic classes like ItemReader, ItemWriter, ItemProcessor. Interestingly, they use generics (something Spring has never thought it was important to support on the DI side). But it‘s hard to see what that does for you really.
I‘m not saying Spring Batch is bad, I would just like to see more. I may try it, god knows it‘s a lot better than Quartz, even after the Terracotta reincarnation… The sad part is, we desperately need things like this. There really are no good ways to do simple scalable and parallelizable jobs. If you are running in a container, you should not use the wonderful threadpool classes in the concurrency framework. You could fire up a message queue, but 15 years in on Enterprise Java, that prospect seems like overkill and even if you did do that, you would have to add a lot of the stuff we are talking about here: tasks, etc.
Call me old school, but when I read a doc for a Framework, I want to see what all it‘s going to do for me, and what I have to do to make it do those things. At one point, they talk about scaling your jobs and I expect to see some discussion of concurrency, queueing, etc. Instead, there‘s a meek, yawning kind of ‘well, we‘re not really hadoop, but if you close your eyes you can make believe.‘
This gets to the core of my issues with Spring: it‘s the Al Gore of the programming world: a Tin Man trying to seem earnest whose whole message seems to be ‘point us to a problem and we can apply our approach to giving you a solution.‘ Imagination score? Zero. Excitement score? about the same as the prospect of seeing the surviving members of The Village People in Vegas. Like Al Gore, you get the feeling that you are in the presence of someone who is too impressed with his own powers to hear the constant squeaking as he does his little jig.