Add more information to debug tool output

[mcollovati]

To debug Java serialization issues, the Java platform offers the sun.io.serialization.extendedDebugInfo system property that enables logging of the serialization stack, providing helpful information about objects and fields being serialized.

In the context of the Kit Debug Tool, a suggestion was to automatically set the property, but this may not work well for the purposes of the tool.

Reasons to not apply the property automatically are:

• the flag is read, and its value is stored in a static member of ObjectOutputStream class. This means that, if the property is not set when the JVM starts and ObjectOutputStream is used before the Debug Tool, changing it has no effects because the value has already been read
• When the property is enabled, the stack is printed only if there's a serialization error. The tool aims to discover as many errors as possible with each run, and for this reason, it tracks and replaces unserializable classes with null values, so no stack information will be printed. If the tool does not replace the invalid values, it will provide not value over than simple adding the property.
• When storing the stack trace, the toString() method is used to represent objects If the method fails for any reason (poor written or causing side effects like Hibernate PersistentList) the serialization process will fail, but not because the objects are not serializable.
• The property is used only for serialization. It has no effect during deserialization when the weirdest exception may arise (e.g. SerializedLambda class cast exception)

However, the debug tool can anyway try to profit of the information available when the property is enabled, but we may require the user to:

• manually enable the property at JVM start
• make reflection access to ObjectOutputStream and ObjectInputStream possible by adding the --add-opens java.base/java.io=ALL-UNNAMED instruction

With the above configuration, we will be able to read the current stack when inspecting unserializable objects and then print the gathered information.

For deserialization, it would be helpful to track every object, associate the trace and print it if deserialization fails. However, tweaking deserialization process may be hard because hooks are available only once an object is completely deserialized, and exceptions may have already been thrown.

[mcollovati]

With sun.io.serialization.extendedDebugInfo and --add-opens java.base/java.io=ALL-UNNAMED we can provide useful information both on serialization and deserialization phases. For deserialization lambda class casts we should be able to point to the exactly failing SerializedLamdba, with information on capturing class, functional interface, etc. In addition, we can also retrieve the deserialization path, inspecting the relative serialization info. There may still be a problem with throwing toString, but we can test the method in advance and somehow replace the object with a sensible substitute if it is failing

Since the debug tool is meant to be used only in development, it may be worth to require the developer to set the mentioned flags to running the tool so that we can provide as much info as possible.

[mcollovati]

Another idea may be to implement a Java agent that intercepts relevant Object(Input|Output)Stream methods to gather information.