I think it's a good candidate for improvement. Now seems a good time to do it since we are renaming packages and making breaking changes. It will be worthwhile to prototype the changes in jbatch and see what they entail.

Will the batch artifacts with generics be specified differently in batch.xml, and job.xml where a fully-qualified class name is needed?

Should the spec say anything to enfore item reader, item processor, and item writer all have the consistent generic type, or just let it fail with the default exception from java?

I'd add another question - and obviously I am +1 for this issue: should we enable to register implicit converters on the job or globally (app/cdi context) to enable the reuse of jbatch components?

I'm worried we might be a bit late to this decision.

Though we'd need to construct our own release plan, let's say we were willing to take on the additional process overhead.

Do we know exactly what we'd want the API to look like?

I dug through the old JSR 352 git repo and can point to this compare which shows the API before we removed generics, which I'd imagine closely mirrors Spring Batch.
https://github.com/scottkurz/jsr352-java-net-backup/compare/after-generics-removed..scottkurz:before-generics-removed?w=1
(Sorry there are some unrelated changes in that diff)

Is this what we'd want ?

That's all I can offer today, will look more soon.

Note though that other specs have decided to punt on this until post-EE9:
E.g. https://www.eclipse.org/lists/jakartaee-platform-dev/msg01608.html
though obviously there's something to be said for making this other breaking change along with the package rename.

Also, since no other Jakarta API depends on Batch, we have that working in favor of having more freedom here.

@rmannibucau

should we enable to register implicit converters on the job or globally (app/cdi context) to enable the reuse of jbatch components?

could you please give an example of what you mean? If it's not closely related to the generics idea I'd just say we should defer to post-EE9 but I'm not sure I really am following. Thx.

@scottkurz sure, if you take a simple "chain" reader R -> writer W. Today both use objects so they can coerce as they want and if there is a class cast exception it is user code, not jbatch. Tomorrow R will issue a Record and W will read a Map (for example) because I reuse R and W from a batch component library. Therefore runtime (jbatch impl) will fail.
Indeed we can say user can wrap the components but it is against the reusability and the whole component model (if so we would better inject a jbatch state saver than handle the flow in the framework).
This is where the ability to register implicit mappers/converters when launching the job+in cdi comes from.
Side note: can also require to define a generic Record type to have implicit coercing as Apache Beam/Spark/Flink and most workflow frameworks do to be able to work on generic flows but it can comes later since we wouldnt break composition with converters at least.

Hope it makes sense.

I agree this seems like a good focus area where there's opportunity for improvements. I think we want to look at when to incorporate existing CDI constructs like maybe interceptors/decorators and when to invent things that are more batch specific.

I'd rather decouple this from the generics discussion, though. It seems like it could stlil be an incremental step forward to define generic-typed artifacts, and if later we added more item conversion capabilities, that would be even better. And mainly, it's because I don't see us resolving this in time. The 2.0 release date on our https://projects.eclipse.org/projects/ee4j.batch project page is 2020-04-01, so I'm not even sure the generic change is doable.

Opened #16 to follow-up on the item conversion ideas.

My understanding is we can do a 2.0 iso the previous one and then do 2.1, 2.2 etc independently of jakarta and jakarta will catch up the version after so maybe just push all new features for after?

We should look at ideas that would not require breaking source compatibility, such as doing this in a set of subclasses as in:
https://github.com/apache/geronimo-batchee/blob/master/extensions/extras/src/main/java/org/apache/batchee/extras/typed/TypedItemReader.java#L28

Maybe there's a way to leverage interface default methods too.

Linked the text from the original JSR 352 issue, in a re-opened issue: #83 (which I closed as dup).

While deprecating the existing, non-generic-typed interfaces, as in PR #18, is one option, I think we should make sure we have a bit more review and maybe discussion of this aspect. Thank you for adding the PR though Romain.