Kabir Khan wrote:
Looking at https://jira.jboss.org/jira/browse/JBREFLECT-16 I wanted to do the same as I did to make the reflect flavour properly serializable, which was simply to add this to ClassInfo, as mentioned here http://community.jboss.org/message/534270#534270:
[...]
If I do the same for JavassistTypeInfo, then that will load the class. Is that a bad thing? Probably...
The alternative for this simple implementation to work is to save the name and the classloader, and classloaders are not serializable.
Or am I missing something? When deserializing a class should that happen in the same classloader (or one with access to similar classes if serialized out of the vm) as the one that serialized it in the first place? If the answer is yes, then I can go forward with this.
Yes, it should, however that is really up to the serialization implementation to get right. In most cases, folks just use the thread's context classloader or just one static classloader for deserialization. Perhaps in our modular future, we'll see a trend of classes being annotated with identifiers which will locate the correct corresponding classloader on the receiving side.
In other words... don't sweat it, it should be OK.