Design Pattern for Generic Data Types in Spring/Mongo

I'm migrating a phone application to a Spring-based web app sitting on a Mongo db. The cellphone application allowed the user to create tests with different types of questions. The question is always a string, but different types of questions have different types of options/answers.

For example, I might have a simple text question that has a text answer. There might be a multiple choice question, in which addition to the question there are a group of options to choose from.

For the purposes of the phone application we got away with declaring the Question as an abstract class, and having these specific types extend that. Now that we're moving over to a web application I need to recreate these classes as domain objects that can easily be binded to our backend mongo database and integrated with our frontend backbone view.

The old system looked like this:

public class Test {
...
   private List<Question> questions;

}

public abstract class Question {
    String questionText;
}

public class MultipleChoiceQuestion extends Question {
    List<String> options;
}

public class ImageQuestion extends Question {
    List<BufferedImage> image;
}

The above logic has the problem of not letting us automatically serialize/deserialize to the mongo database and it will also pose problems for managing the test as a Backbone entity as we will be deleting and adding questions.

What is the right design pattern for this type of entity relationship to allow for the easiest serialization/deserialization on the front end and back end? I was considering flattening the questions into one generic question type with all possible options and parameters and enumeration of QuestionType to specify which question this is, but that seems like sort of a hack.

What is the right execution for this problem?