Thoughts on adding getElementClass() method to StackTraceElement?
peter.levart at gmail.com
Sat Jun 15 21:43:34 UTC 2013
On 06/15/2013 09:59 PM, Nick Williams wrote:
>> And about adding a way to store the class in the StackTraceElement, one issue is that stack trace element are Serializable, so if an error occurs on a server, the exception can be serialized to the client which is a really nice feature, but if a stack trace element embed the class object, then it means that all the class that are available at server side should also be available at client side.
>> >I have no idea how Microsoft solve this issue.
> Classes are Serializable in Java, so it shouldn't cause a problem with serialization. The elementClass property will be properly serialized and deserialized. If I understand you correctly, you're expressing concern that this could actually be a problem; that we don't want Classes transferred to the client and deserialized. The Class class has a special serialized form that is unlike other classes and is very efficient. Only a descriptor for the class (including its serialVersionUID value) is transmitted, just enough to give the endpoint enough information to locate the class.
That's true when Class objects are serialized with a purpose and intent
that they will be deserialized in an environment where correct versions
of those classes are visible by class initiating deserialization. Stack
trace can contain references to classes that are not visible even by the
class that constructed the Throwable. By exposing Class objects that
would otherwise not be obtainable, there could be security issues.
> There won't be a performance issue here, as far as I can tell. However, I can foresee one potential problem when deserializing the StackTraceElement: if the Class isn't on the class path on the deserializing JVM. This could be handled two possible ways:
> 1) Mark the elementClass property on StackTraceElement transient so that it isn't serialized.
> 2) Add a special deserialization rule (not unprecedented by any means) for StackTraceElement that says that StackTraceElement will not fail to deserialize if the elementClass property can't be deserialized because it couldn't be loaded. (This would be my suggestion.)
> I'm not sure how .NET handles it either, but it clearly does, as its StackFrame class is the equivalent of Serializable.
I think that option #1 is the only realistic option. Who cares about
classes in the de-serialized stack-trace. The only thing needed is their
names so that the stack-trace can be printed.
More information about the core-libs-dev