通过 TCP 套接字发送对象 - ClassNotFoundException

Question

I have two simple applications: client and server. Client encrypts (simple AES) custom object and sends it through TCP socket, as bytes, to the server. Server decrypts those bytes and calls the method that recreates this object, like this:

private static Object getObjectFromBytes(byte[] credentials) throws IOException,      ClassNotFoundException{

    ByteArrayInputStream bis = new ByteArrayInputStream(credentials);
    ObjectInput in = null;
    Object credentialsObj = null;

    try {

        in = new ObjectInputStream(bis);
        credentialsObj = in.readObject(); 

    } finally {
      bis.close();
      in.close();
    }
    return credentialsObj;
}

On the client side, when I'am encrypting this object, it is of type mds.hm5.client.ITU_Credentials . On the server side, when I'm decrypting it and converting back to object, it should be mds.hm5.tokenservice.ITU_Credentials . Instead I'am getting the following exception:

java.lang.ClassNotFoundException: mds.hm5.client.ITU_Credentials

He is looking for this object by the old classpath. Why is it happening and how should I fix it?

Additional information:

Here is how I convert this object to byte array on the client side:

private static byte[] getBytesFromObject(Object credentials) throws IOException{

    ByteArrayOutputStream bos = new ByteArrayOutputStream();
    ObjectOutput out = null;
    byte[] newBytes = null;

    try {

      out = new ObjectOutputStream(bos);   
      out.writeObject(credentials);
      newBytes = bos.toByteArray();

    } catch (IOException e) {
        e.printStackTrace();
    } finally {
      out.close();
      bos.close();
    }
    return newBytes;
}   

The reason why I use generic type Object is because I am going use those methods to convert/encrypt/decrypt multiple types. Is it the proper way?

Answer 1

On the client side, when I'am encrypting this object, it is of type mds.hm5.client.ITU_Credentials.

So that's what it is in the serialized stream.

On the server side, when I'm decrypting it and converting back to object, it should be mds.hm5.tokenservice.ITU_Credentials.

No it shouldn't. It should be the same as when you serialized it [unless you have taken certain magic steps, which clearly you haven't. Without those magic steps there is no magic, and nothing to connect mds.hm5.client.ITU_Credentials with mds.hm5.tokenservice.ITU_Credentials whatsoever]. You have two different classes with the same name and different packages, one in each location. They aren't the same.

He is looking for this object by the old classpath.

You are confused between CLASSPATH and package name. They aren't the same thing. It is looking for this object by its actual package name. What else can it possibly do?

Answer 2

The object output stream doesn't serialize the class itself but only its state (the field values). The receiver needs the class file on it's classpath.

It is possible to transfer the class too. You'll have to find (or write) a classloader that can load the class from your connection. If you have an URL for your classfile then you could use the URLClassloader. Then you don't have to add the class to your classpath.

Answer 3

Your client neeeds to have in its classpath the .class files that define the object. What you are doing is serializing/deserializing the instance, not the class.

Answer 4

Late, but it may be useful for someone in the future: I wanted to send an object Message whose package was entities in the client side, but in the server side this Message class was not nested within a entities package, so this Exception was thrown. It may be dumb but I spent many hours figuring out this.