The problem is Gson is attempting to use reflection to access a private field of some class in the java.lang module.
In the days before Java 9, this was fine. With Java 9 this can throw exceptions.
The quick and dirty workaround would be to use an -add-opens option to the java command line. See the first reference for more information.
Another option would be to implement a custom object mapper to serialize / deserialize the JDK class (or classes) that triggering this. It is a bit dodgy for your application's serialization / deserialization to depend on the details of private fields of JDK classes. They may change, causing your application to break without warning.
(My guess is that this is caused by the errorInformation field ...)
For more information about these options, see:
I checked the Docker image I'm running this in and it does appear to have been updated recently.
Yes. It looks like you are using the newly Java 16 EA release now. I'm not sure this is advisable. It is certainly inadvisable to have your docker image updated under your feet. You should be developing against a specific target (major) version of Java.
UPDATE
However, for this problem to have "suddenly" started happening due to Java version change in your container, the previous version must have been Java 8 or earlier.
On reviewing the Java 16 page on the OpenJDK site, I see that it is implementing JEP 396: Strongly Encapsulate JDK Internals by Default which would have the effect of stopping Gson from messing with the access of private fields. If you read the JEP there may be another workaround.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
