Jenkins core and plugin code make use of two kinds of serialization of Java objects: to XML files like
build.xml or global settings, via XStream; and using Java’s built-in serialization mechanism, for Remoting calls. In either case you may see a warning from
Bad serialization of ParametersAction.parameterDefinitionNames
Report uses of anonymous classes in outgoing Remoting packets
(There are variants, less common, for attempts to serialize lambdas or local classes.) The warning will be logged by
org.jenkinsci.remoting.util.AnonymousClassWarnings. If you see this warning, track down the location in source code:
will give you an overview of the class, and
LineNumberTable entries will show you which lines in
YourClass.java contain the class declaration.
Usages in Remoting
The main problem with sending anonymous classes over Remoting is that can all too easily “capture” unexpected and unwanted fields in the callable, which may cause serious issues including those described in Plugins affected by fix for JEP-200. Also you will get unusable listings from metrics collected as of JENKINS-27035 - Request/response statistics Resolved .
To fix code like this:
just use a “convert anonymous to member” refactoring in your IDE, or manually:
Usages in XStream
If you have accidentally used an anonymous inner class as a field in some object serialized via XStream, your XML files are going to be a mess. This is a worse problem than for Remoting since not only can you suffer from JEP-200-related security blocks, but the mistake has been persisted to disk so you need to take into account possible saved settings.
If the field was not really valuable, make it
transient (so it will not be saved), and also rename it so Jenkins will not even try to load existing values from disk.
If you can afford to discard old settings, fix its type and rename it.
If you really need to load existing settings, you are going to have to do some work to retain compatibility. If
YourClass$3 was saved to disk, originally from
then you can refactor this way: