Broken encapsulation of job parameter attributes

[fmbenhassine]

As of v5.2, the name of a job parameter lives outside the JobParameter class. It is currently used as a key of the internal map of JobParameters while it should be part of the JobParameter concept. I could not find the context of this design decision, but this has a couple issues:

• Part of the state of an entity/value object is "detached" and lives outside the entity/value object
• As a Spring Batch user, when I have a reference to a JobParameter, I cannot get its name without having to look for the parent JobParameters

I believe the name of a job parameter should be part of the JobParameter class (which could be a record by the way) and the JobParameters class should hold a set of job parameters instead of a map from "name" -> "parameter concept without a name".

Technically, this means changing this:

public class JobParameter<T> {
	private final T value;
	private final Class<T> type;
	private final boolean identifying;
}

public class JobParameters {

	private final Map<String, JobParameter<?>> parameters;

}

into this:

public class JobParameter<T> {
        private final String name;	
        private final T value;
        private final Class<T> type;
        private final boolean identifying;
}

public class JobParameters {

	private final Set<JobParameter<?>> parameters;

}

This provides a better encapsulation of job parameter attributes and makes the interaction with the JobParameter/JobParameters APIs easier that something like this (which is very frequent in the code base):

Map<String, Object> result = new HashMap<>();
for (Entry<String, JobParameter<?>> entry : jobExecution.getJobParameters().getParameters().entrySet()) {
	result.put(entry.getKey(), entry.getValue().getValue());
}