Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

A Quick Look at Spring Batch

DZone's Guide to

A Quick Look at Spring Batch

· Java Zone
Free Resource

Are you joining the containers revolution? Start leveraging container management using Platform9's ultimate guide to Kubernetes deployment.

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.

 

From http://www.jroller.com/robwilliams/entry/a_quick_look_at_spring

Moving towards a private or Hybrid cloud infrastructure model? Get started with our OpenStack Deployment Models guide to learn the proper deployment model for your organization.

Topics:

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}