This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.To start at the beginning, follow the link to the first post.The next post in the series is
here.
This series is also available as a podcast on iTunes, Google Play, Stitcher, or use the link to the RSS feed.
-----
So you’ve decided that you might want to write (or rewrite) some batch applications in Java. The next question is whether you just want to sit down and write it or if you want to make use of a framework. There are several and, as you might imagine, I’m a bit biased toward JSR-352/Jakarta Batch. But which framework isn’t our question..for this week we’re just looking at whether you should consider any framework or just write it yourself.
I’d like to start by making a distinction between using a formal framework and just stealing/copying code. Even before the days of the internet and readily available code samples, people stole code (or called it reuse). Probably everybody has, at one time or another, asked around to see if anybody had some code that did <this thing you needed to do>. Maybe because you didn’t know how or maybe you were just hoping to avoid having to type it all in. This is all just fine (well, up to a legal point anyway), but not what I’m talking about with a framework.
A framework, to me, is a formal pile of code intended to make whatever you’re doing easier, every time you have to do it. Even if you only intend to do something once, having a framework can make it easier.
Of course, on the other hand, having to figure out how to use a framework and sometimes force what you need to do into the structure the framework requires can end up being extra work. Especially if you think you’re only going to do this once.
So what to do? Well, sure if you’re just throwing together some quick little thing that is mostly code lifted from other things, the risk is low, you get results fast and all is good. For now anyway. Over time those quick little things tend to grow, and get more complicated. Somehow that temporary utility you wrote to hold things together until something fancier gets done ends up still being used, maybe for something else entirely, 10 years later.
And thus I tend to come down on the framework side. It might be a pain to get started with, but once you’re past those initial hurdles the next thing will go easier. And there’s a bunch of code you don’t have to write and, more importantly, not maintain.
Frameworks are not only maintained by somebody else, they are (usually) used by a lot of different people for different sorts of things and that tends to shake out bugs, making it more stable for everybody. And perhaps the risk of breaking a lot of people tends to make those writing fixes (or new features) a bit more cautious.
You could stretch this argument and say it means you should only buy software off the shelf and never write your own stuff. I’m not saying that. At some point your particular needs take over, but there’s a lot of stuff there’s no reason to write again and again. Let the framework do the drudgery and own the stuff that’s unique to your situation.