We'll first check that the class has a no-args constructor. This is not strictly necessary as long as the serialization mechanism can construct an instance, but problems have turned up when the serialization mechanism is GSON, and constructor injection is employed. The problem is that if a no-args constructor is not present, GSON will use 'Objenesis' to instantiate the object, which will not invoke /any/ constructor. This is not a problem in itself, but if the class has a field that uses declaration initialization (i.e. private List<String> list = new ArrayList<>()), then this field will not be initialized when no constructor is invoked, and thus be null. The mechanism that we use here to find the fields that Spring has injected will thus assume that this field is an injected field (it is present in the bean instance, but not in the newly instantiated instance), and thus it will be stored as a template field, and thus it will NOT be assumed to be state: It will be assumed to be a shared service of sorts, and thus shared between all stage processing threads. Which is close to opposite of what you expected, and will lead to very strange and hard-to-debug problems. Thus, we check that the class has a no-args constructor, and if not, we currently (2023-09-16) log hard - WILL LATER THROW.
Later, we'll throw if this is missing.
Here's the code comment for this:
We'll first check that the class has a no-args constructor. This is not strictly necessary as long as the serialization mechanism can construct an instance, but problems have turned up when the serialization mechanism is GSON, and constructor injection is employed. The problem is that if a no-args constructor is not present, GSON will use 'Objenesis' to instantiate the object, which will not invoke /any/ constructor. This is not a problem in itself, but if the class has a field that uses declaration initialization (i.e.
private List<String> list = new ArrayList<>()), then this field will not be initialized when no constructor is invoked, and thus be null. The mechanism that we use here to find the fields that Spring has injected will thus assume that this field is an injected field (it is present in the bean instance, but not in the newly instantiated instance), and thus it will be stored as a template field, and thus it will NOT be assumed to be state: It will be assumed to be a shared service of sorts, and thus shared between all stage processing threads. Which is close to opposite of what you expected, and will lead to very strange and hard-to-debug problems. Thus, we check that the class has a no-args constructor, and if not, we currently (2023-09-16) log hard - WILL LATER THROW.