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.
------

In the next few entries we’re going to have a look at JSL and how you can substitute values into the JSL.  There are a lot of different reasons to do that and some interesting possibilities.  But before we get into all the details, let’s have a look at where substitution values can come from. 

Our first source of substitution values comes from outside the job.  They come from whoever submitted the job.  Different implementations might provide some alternate ways to submit jobs, but the only way provided in the specification is through the ‘start’ method on the JobOperator interface.  We’ll get to JobOperator eventually, but for now just know that the ‘start’ method allows you to provide a Properties object containing job parameters.

These parameters are key/value pairs (as you’d expect in a Properties object), where the key and values are both Strings.  Be careful with this.  The key and value for a Properties object are supposed to be Strings.  However, since Properties inherits from Hashtable you can use the ‘put’ method to add things in there.  Don’t do that.  It is discouraged in general for Properties objects, but JSR-352 expects all Job Parameters found in the Properties object to be Strings and any other type won’t resolve when you try to use it. 

That said, you can provide Job Parameters to direct flow control within the job or to pass values into executable parts of the job (i.e. to a batchlet or other artifact).  We’ll see the actual syntax to process Job Parameters in a later post.  For now, just realize that basically any value used in the JSL can include strings that are resolved from Job Parameters.  That includes not just Properties injected into batch artifacts but other values like package and class names used in the ‘ref’ attribute of an executable element (like a batchlet).  I’m not entirely sure why you would want to do that, but you can.

We haven’t gotten to job restart processing yet either, but the specification also allows for different Job Parameter values to be specified on the restart of a failed job than were used in the initial start.  That could be handy if there are differences in how things need to work in a job doing restart processing.  Might also be a handy way to let the job itself KNOW it is being restarted…