How to serialized Multipart File class in java

Question

Anybody know how to serialize org.springframework.web.multipart.MultipartFile class

In sonarqube its shows as a critical issue.

Answer 1

Those sonarqube rules are trying to tell you about a potential programming problem.

If you're not going to try to figure out what the problem is, you should just disable sonarqube entirely. From your question it is not clear if you actually want to serialize the class that contains this field, or if you just want to fix the problem that this error is showing, or if you just want to get rid of the message without caring about the underlying problem it is trying to inform you about.

I want to just get rid of the message

Easy! Just uninstall sonarqube. Much nicer than throwing in random keywords you don't understand.

I want to know about the underlying problem

Java has a so-called serialization mechanism built-in. serialization is the idea of taking an object and turning it into a stream of bytes, so that you can store it in a file, send it across a network, etcetera.

The problem is, MultipartFile is not designed to be serialized. However, the class that this private MultipartFile file; field is in, is saying that it can be serialized, and that is the problem: It says that. But it's not true.

Most likely, the mistake you made (if we can call it that, it's not much of a mistake) is that you've erroneously tagged the class containing this field as serializable. Do you actually serialize this thing? I am assuming you are not.

So, do you actually have an intention to serialize this object? I'm assuming you do not. Unless you are explicitly calling e.g. .writeObject(someInstanceOfThisclass) on an ObjectOutputStream or similar, you aren't serializing this.

You have no intention to serialize this

One downside of the serialization mechanism is that once a supertype decides that you are serializable (done by implements the java.io.Serializable interface), then you just are, and you can't then mark down: Actually, no, I'm not. So, to get rid of this warning properly is to ensure that no supertype of yours 'extends Serializable'. If you can do that, do so. For example, if you have decided to extends HashMap, don't do that - instead, implements Map, make a field of type HashMap, and make one-liner implementations of all methods in Map that just invoke your hashmap field.

However, if the type you are implementing/extending that itself implements Serializable cannot be removed from your supertypes, then there is an alternative. To do this, add the following methods:

private void writeObject(ObjectOutputStream out) throws IOException {
    throw new IOException("Not serializable");
}

private void readObject(ObjectInputStream in) throws IOException {
    throw new IOException("Not serializable");
}

by doing this, it's clear from the code that you explicitly intended for this class not to be serializable, and sonarqube will figure that out too: The sonarqube issue will disappear when you do this.

Actually I do want to serialize this

Ah. That's a much bigger problem, as MultipartFile doesn't let you. Your only solution is to get rid of the multipartfile field entirely and replace it with something that is serializable (such as a list of strings, a byte array, etc), or write your own code to produce a sequence of bytes such that you can restore this MultipartFile back from that sequence of bytes later. This probably means you need to store all those bytes, that could be painful - that might be a lot of them.

To do this, override those same methods, but actually implement something instead of throwing that exception. Writing your own writeObject method is a bit complicated, but you can find plenty of examples by searching the web.

If you don't actually care about this field, then presumably, just.. remove the field. Why have it?

You could mark the field as transient. However, that means that if this object is serialized and then deserialized, it will be null. what point is there in allowing yourself to be serialized? transient is primarily useful for fields that represent cached data, which are only accessed by methods that will just (re)calculate if the field is not initialized. A trivial example is if your hashCode() method is a potentially expensive operation.