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.
-----
I could probably stretch this out into several different posts, but it is beginning to feel a bit repetitive. We’ve talked so far about flat file readers and writers and CSV readers and writers. Fundamentally we’re just reading and writing plain text files with some internal formatting and either parsing the syntax or taking an object and putting its attributes into that syntax.
JSON files and XML files really aren’t any different. The mechanics are all the same, it is just a matter of how you handle the format within the file. Ok, XML is a bit more complicated because you don’t just have one record of the file as a single thing to read. In fact, as I think about it now, what would you do reading an XML file in as input to a chunk step? I guess you could have an outer element that defined a list of some sort and then inside it a bunch of the same element over and over. You’d parse those inner repeated elements to pull out the attributes and that’s the data for your Read results.
But a more complex XML file…? Maybe there’s something specific in there you’re looking for and you’d just parse along until you found it I guess..
Anyway, back to the topic.. BatchEE and JBeret both have reader and writer implementations that can handle these formats too. There’s a STAX based XML reader. There’s a Jackson JSON parser, along with a JSON-P parser. There are probably some more in there I missed.
And all of them have a bunch of injected parameters to let you manage and control what it is doing and to help it map the data it is reading into an Object (or map the Object into data being written). Certainly none of these is just going to magically read your particular JSON or XML and produce your intended Object.
But, like a lot of the other implementations we’ve discussed, these handle all the basic mechanics for you. You just need to figure out what parameters to feed it and what other things you need to implement specific to your data. The boring generic stuff is done.