As discussed as part of #23411, running multiple Batch jobs does more harm than good, as @benas summarised nicely:
I would not continue the support for running multiple jobs at the same time, because this is problematic in many ways: Same arguments are passed to all jobs (as mentioned by Stephane), mixed logs, ambiguous job execution order(ing), confusing exit code, etc. I can elaborate on each of those, but I believe there are obvious reasons why the current behaviour is confusing. So following the unix philosophy of making one thing do one thing and do it well, I would change the current behaviour to run a single job at a time.
We can continue supporting packaging multiple jobs in the application, but when that's the case we should require users to identify via a property which one job they want to be launched. This will require us to deprecate spring.batch.job.names and replace it with spring.batch.job.name (or spring.batch.job-name).
Comment From: hpoettker
For the use case of multiple jobs packaged in the same application, it would be a great enhancement if lazy initialization for the job beans worked (more or less) out of the box. Ideally, only the beans required for the requested job are actually initialized while all other job beans and their dependencies remain uninitialized. For larger applications, this should yield a sizeable improvement of the application start-up time.
Currently, job configuration classes can be explicitly marked as @Lazy or the property spring.main.lazy-initialization can be set to true. However, all job beans will nevertheless be initialized when injected into JobLauncherApplicationRunner::setJobs or latest when Job::getName is called on the job beans, respectively.