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.
Last week we, ok, I, concluded that in a lot of cases using a framework of some sort to help write Java Batch applications is probably a good idea (enough weasel words in there for everybody?). In essence, a framework gives you reusable code to do a lot of the things you’d have to do yourself, and maintenance of that code is separate from the stuff you have to write.
This week we’ll go one step further and consider whether you should prefer an open or proprietary framework. Obviously I’m thinking of JSR-352/Jakarta Batch as the open framework. There are a few different proprietary ones (you know who you are) and my intention here isn’t to get into a debate about the differences between them.
This is basically an open vs. proprietary question. And we’re only really considering this if you’re starting fresh. If your environment has a long history with one of the proprietary frameworks, you’re unlikely to just suddenly switch everything over.
Or maybe one of the proprietary frameworks has some feature that you just have to have and it isn’t in Jakarta Batch. Well, now that’s an interesting point. If you’re using a proprietary framework and there’s some feature you need that it doesn’t have, all you can really do is open a requirement against whoever owns it, maybe enlist some other users of that framework to join in, and try to put some pressure on the owner to do the work.
An open framework is open to enhancements. You may need to do the same political work to get others interested, and maybe somebody else will be interested enough to even do the work. But you can also do the work yourself. That’s not really an option with most proprietary frameworks.
I’m not going to rehash all the arguments in defense of open source etc. But I will point out that even if you’re using an open source framework, you still need to get support from somewhere. If it is always going to be you trying to figure out what the problem is when bad things happen, maybe you are better off writing it all yourself. For production mission-critical applications, you really want somebody you’re paying to be on the hook to help get things working again.
There are clear benefits to open source, but being able to get support when you need it is also really important.