WebSphere Application Server & Liberty

 View Only

Jakarta Batch Post 140: Extras – Reading and Writing Excel Files

By David Follis posted Thu June 03, 2021 08:06 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

More specialized readers and writers for quirky file formats?  Seriously?  I swear this is probably the last one.  Not that there aren’t more, I’m just running out of ones I find interesting enough to talk about (which is, perhaps, well past what you’re interested in reading about).

So you’ve got some spreadsheet that you need to process with your batch job.  Wouldn’t it be easier to just export the thing into a .csv file and read that?  Or maybe you’ve got to look at the results of a batch job in Excel.  Wouldn’t it be easier to just write a .csv file and import it?

Well, maybe.  But possibly the spreadsheet you have to process gets emailed (or sent in electronically some other way) and converting it to a .csv would require some manual intervention.  Nobody wants to be the person who has to go do the dumb format conversion so the stupid batch job can read the file. 

Or maybe the result of the job gets emailed to some executive and you don’t want to have to explain to them how to import a .csv into their spreadsheet application.  They want a .xlsx file because that’s what spreadsheets are (no offense to any executives reading this of course). 

Or…maybe…you’re trying to write a job that does an automatic conversion of a .csv file to/from a spreadsheet.  There’s no ‘processing’ involved but just a straight up format conversion step. 

For all of that sort of thing you’ll need an Excel reader or writer.  And, these things being what they are, you’ll need one that can handle the various incompatible format changes that seem to come along now and then.  Which means this isn’t necessarily as simple as it might sound..and it probably requires some ongoing upkeep over time. 

Of course, this….. isn’t being done with specific knowledge of the file format buried right there in the reader/writer.  They’ve exploited Apache POI which exists to handle Office Open XML standards and that’s where the magic happens.

Alright…I’m done with flat file readers and writers, at least for a while.  Next week, something new-ish.

Oh, and of course “Excel” is a trademark of Microsoft.  Lest we forget.