Making JavassistTypeInfo serializable

[kabirkhan]

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:

   protected Object writeReplace()
   {
      return new MarshalledClassInfo(getType());
   }

   public static class MarshalledClassInfo implements Serializable
   {
      private static final long serialVersionUID = 1L;

      Class<?> type;

      public MarshalledClassInfo(Class<?> type)
      {
         this.type = type;
      }

      protected Object readResolve()
      {
         TypeInfoFactory tif = new IntrospectionTypeInfoFactory();
         return tif.getTypeInfo(type);
      }
   }

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.

[alesj]

If I do the same for JavassistTypeInfo, then that will load the class. Is that a bad thing? Probably...

I wouldn't bother too much with this -- TypeInfo/ClassInfo serialization shouldn't concern itself with lazy-loading.

Or, if this actually becomes a problem -- which I very much doubt -- then we'll change the mechanism for JavassistTI, OK? ;-)

[dmlloyd]

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.