Bug 4991 - Add Java Based JSL
Add Java Based JSL
Product: jbatch
Classification: Unclassified
Component: SPEC
PC Windows
: P5 enhancement
: ---
Assigned To: ScottKurz
Depends on:
  Show dependency treegraph
Reported: 2013-05-11 03:37 UTC by reza_rahman
Modified: 2016-03-17 17:13 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description reza_rahman 2013-05-11 03:37:38 UTC
It would be very useful for a future version of the specification to add support for a type-safe Java JSL like the following:

public Job buildJob() {
    return JobBuilder

This would be more dynamic, fluent and readable than the current XML JSL.
Comment 1 reza_rahman 2013-05-11 03:53:02 UTC
Do let me know if anything needs to be explained further - I am happy to help.

Please note that these are purely my personal views and certainly not of Oracle's as a company.
Comment 2 mminella 2013-09-16 17:43:08 UTC
Spring Batch provides a similar configuration option using job and step builders (instead of a single builder as proposed previously).  You can read more about it here: http://docs.spring.io/spring-batch/reference/html/configureJob.html#javaConfig
Comment 3 rmannibucau 2015-09-05 09:08:44 UTC
+1, only open points for me are:

- do we use typed blocks (end of a chunk ends with end() or done() to go back upper level), think it is better to do so to avoid to mess options (typically properties can be messy if not done)
- not explicit but properties should be typed (property("mySuperProperty", new MyValue()) to get @Inject @BatchProperty MyValue value)
- Do we use @Produces or a batch event where we can register jobs (I prefer this last option, ie void addMyBatches(@Observers BatchRegistration br) { br.newJob("myJob")....; })
Comment 4 ScottKurz 2015-09-21 16:10:47 UTC
So first, I think this is a fair topic to consider for 1.1.

Looking back at the mailing list discussions ( and some of the earlier EG minutes), e.g. discussion starting here:


It's clear that the EG did not reject the idea (which would mean we really should only reconsider in a new JSR with a new EG), but simply de-prioritized, recognizing the complexity.

I think a key question of direction is whether we intend this to be a full, parallel job definition mechanism, or only one usable for some simple subset or special cases.

As I start to think through the "full, parallel" mechanim, it seems some cases wouldn't end up that much simpler than using the standard JAXB model (OK, maybe you'd cut out some intermediate objects along the way).

So I think my point is:  what are we really getting out of this API?  Is it more about keeping simple cases as simple as possible?   Or are there more specific Java patterns we're enabling in doing so?  E.g the type-checking in Reza's original example.  Or is it the ability to start the job "anonymously" by-reference handed back from the builder (which could conceivably be added in a new JobOperator method:  startInline(String,Properties)?   

One thing to be wary about in doing only a subset:  assuming we might one day want to expand to the full JSL-based definition capability, we probably want to consider how this should be done for future compatibility.
Comment 5 ScottKurz 2016-03-17 17:13:06 UTC
Closing this:  no one's working on this actively, plus I personally consider it unlikely we'll get to it, plus there's not a huge amount of specific detail that will be abandoned in closing this.