> The docker-java library is not a direct dependency of the docker plugin but is pulled in transitively through the docker-java-api plugin. Would it make more sense to whitelist the classes in that plugin instead if they can be safely serialized?
This library is generally a risky thing, because it does not consistently retain binary compatibility. That's why it has been originally shaded in plugins like Docker, Yet Another Docker Plugin, Docker Traceability, etc. So a user of such API library may find his plugin broken by a library update. Maybe the situation became better over years, Kanstantsin Shautsou improved Docker Java's lifecycle a lot
Apart from that, +1 for moving whitelist to a library in the current state.
> I think that whitelisting the classes in the com.github.dockerjava.api.model package is probably ok
I have reviewed all classes, and yes they are OK in the current version.
OTOH the whitelist does not seem to be enough. com.github.dockerjava.api.command.InspectContainerResponse$Node is not whitelisted. The serialization of InspectContainerResponse may fail if the field is not null
> but serializing the 2 commands in the com.github.dockerjava.api.command package seem like an accident where an inner class picks up a parameter or local variable
Yes, InspectContainerResponse$ContainerState and InspectContainerResponse$Node inner classes are not static. Making them static would break binary compatibility. It may be acceptable for Docker Java tho.
Probably it's fine to keep it whitelisted. E.g. InspectContainerResponse is also explicitly persisted in the Docker Traceability plugin (within https://github.com/jenkinsci/docker-traceability-plugin/blob/49141a86d41269799e00161a02ac72e9aa9a3a15/docker-traceability-api/src/main/java/org/jenkinsci/plugins/docker/traceability/api/DockerTraceabilityReport.java#L51). This does seem to be a valid use-case for serialization though it makes the plugin affected by JEP-200 for sure. I will create a ticket