Hi Scott,
Maybe coming from nowhere but personally i'd like jbatch 2 to not inherit from jbatch 1 and be reactive driven.
Overall idea is to be able to use more easily custom flows (by combining CompletionStages).
This has a ton of advantages:
1. Makes the batch writer responsible of the flow (whereas a mix between the runtime and writer),
2. Keep the composability of existing batch "components",
3. Enables to work with any IoC without having to do any integration (batch writer injects what it needs),
4. No need of any batch/job repository (in code veritas est ;)),
5. Enables to be more efficient in more and more common "remoting first" batches we meet with microservices (ie leverage NIO more than in current synchronous API),
6. Makes the testing way easier: myBatch.userStart().toCompletionFuture().get();
The main missing piece is the persistence of the steps+overall batch state(s) and some controller (to stop a running batch for example).
Indeed JBatch 2 can be a BatchController { saveStepState(...); saveBatchState(...) } etc but thinking more in terms of events sounds more natural (we can start by CDI events since it is about jakarta but implementations can wire events on what they desire).
To rephrase it a bit more clearly: JBatch wouldn't be a runtime with very low value as of today but the actual infrastructure API (persistence mainly and state "isBatch(key, STOPPED)").
In terms of API the only small challenges are to enable to inject into a promise flow these persistent steps properly and to probably enable to orchestrate more easily chunking and so (even if Stream API kind of enables it but it misses some Iteration object to make it easier) but overally it does not sound crazy:
final var batch = jbatch.startingBatch("my-batch");
final var batchPromise = batch.wrapStep("step 1 name", fetchData())
.thenApply(read -> batch.wrapStep("step 2 name", processData(read)));
and so on.
Does it make sense or is JBatch stucked on container+synchronous current design?
