Thanks for your proposal, but I do not think this would be better.

The reason I didn't want to wrap the JSR 352 APIs in our APIs in the first place is it would actually limit what users can do. For now there are just a few methods that use parameters (start, restart), but the JSR 352 spec might add more in the future. For instance startInThreadPool(String threadPoolName, String jobName, Properties parameters). Or even a JSR 352 runtime could provide its own, alternative interfaces that accept a job name and job parameters. If we forced users to go through our APIs, we would have to maintain them to keep them in sync with the JSR-352 APIs. I don't really want to do that.

I guess we could provide your syntax as an optional, alternative syntax and keep the current one, but I honestly don't see much value in it. Why use our wrapper when you can use the standard syntax?