WebSphere Application Server & Liberty

 View Only

JSR-352 (Java Batch) Post #169: Batch Jobs in Java?

By David Follis posted Thu February 03, 2022 08:02 AM

  
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 iTunesGoogle PlayStitcher, or use the link to the RSS feed
-----

When I started this blog over three years ago I began with this question.  In the coming weeks I’ll be looking back over all the things we’ve covered and reconsider the question.  I’ll take it in parts and this week we’ll just look at Java itself.

So, whether you’re writing some new application and trying to decide what language to use, or you’ve got an existing application you’re considering rewriting, should you consider Java?  Rewriting existing applications is expensive and introduces risk.  You need to be sure you understand why you’re doing it.  Don’t just wave your hands and say ‘modernization’. 

But either way, our question here is whether you should consider Java for batch applications.  I certainly think so.  I’m not saying that Java is the only language to consider, but it is certainly a good option.

Batch applications need access to data sources.  They read it from somewhere and write things somewhere.  Java has mechanisms to access pretty much anything, including some fairly obscure things (well, ok, my obscure might be your everyday data and vice versa, but still). 

Being object oriented makes Java pretty good at handling a ‘row’ of data as attributes of an object.  It just fits pretty well into the language.

Performance is always a concern with batch.  It can’t take days to run your hourly job.  Here again Java is pretty good because the JIT does a better and better job of optimizing the generated object code the more it runs the same code, and batch applications do tend to run the same code over and over again.

And, of course, Java is supported pretty much anywhere you might want to run your batch application, so you aren’t tied to a particular platform.  That lets you make a platform decision based on other considerations (reliability, cost, performance, etc.).  I’m not going to get into that argument here.  My point is that choosing Java as a language for batch removes language choice as a factor in choosing a platform…although you might consider that Java runs better some places than others (looking at you IBM Z).  

Ok, so I think we’ve shown over the last three years that the answer to this first question is probably ‘Yes’.  Next week we’ll dig in a little farther..
0 comments
67 views

Permalink