Details
-
Fix
-
Status: Released (View Workflow)
-
Minor
-
Resolution: Fixed
-
2.5.4, 2.6.1
-
None
Description
Note
- This issue exclusively applies to User-defined Java Jobs that make use of the step.getAllArguments() method.
- There is no impact on JavaScript Jobs.
Current Situation
- The method step.getAllArguments() returns a map with argument names (String) as keys and JobArgument instances as map values.
- The JobArgument instance utilizes a generic type that should correspond to the type of the argument value.
- Typically, arguments are declared in a separate class to specify the type, default value, display mode, and more.
- Example:
public class MyJobArguments extends JobArguments { private JobArgument<String> myString = new JobArgument<>("myString", false); private JobArgument<List<String>> myList = new JobArgument<>("myList", false); public JobArgument<String> getMyString() { return myString; } public JobArgument<List<String>> getMyList() { return myList; } }
- Within the Job, the declared arguments can be retrieved using the step.getDeclaredArguments() method and typed accordingly:
JobArgument<List<String>> myListArg = step.getDeclaredArguments().getMyList(); List<String> myListArgValues = myListArg.getValue();
- Conversely, the step.getAllArguments() method provides JobArgument instances for all arguments, whether declared or not, and incorrectly uses the type of the Arguments class instead of a wildcard type:
JobArgument<MyJobArguments> myListArg = step.getAllArguments().get("myList");
- it works
MyJobArguments myListArgValues = step.getAllArguments().get("myList").getValue();
- this results in a ClassCastException because the argument value is of type List<String>, not of the type MyJobArguments.
- Example:
Desired Behaviour
- The step.getAllArguments() method should utilize the wildcard type.
JobArgument<?> myListArg = step.getAllArguments().get("myList");
Object myListArgValues = step.getAllArguments().get("myList").getValue();