Hi!
Fresh to the list and don’t know how detailed Sebastian and Romain already described the problem I do have.
I’m using Apache Johnzon in production and we have quite a few different use cases.
First of all there is an important distinction between sending and receiving JSON on an ‚external‘ interface, like a REST service - or using it internally as kind of replacement for java serialisation.
In the first case we must not allow to inject any kind of type information from external. That would mostly end up opening security holes like we’ve seen in the Java serialization vulnerability. We don’t wanna go down that route for _external_ interfaces.
If we are talking about internal interfaces it’s all different. Here we do not need to be as restrictive as with external ports.
Most of the times the system which does the serialization/deserialisation doesn’t even know the objects Classes.
Think about a process engine which stores the process variables as JSON. The process engine obviously doesn’t have any clue how your business objects do look like. Your business DTOs also might not know that they are subject to be stored as JSON string.
Now where is the problem?
Let’s assume we have a
public abstract class Person {
private String name;
}
and
public class Customer extends Person; and
public class Employee extends Person;
If you have an instance of
public class Task {
private Person assignedTo;
}
then you have no clue if the Person is a Customer or an Employee.
But we could store this information away as Sebastian already showed you:
{ „person“, {„//javaType“: „com.acme.Customer“, „name“: „hans“}}
something like that.
The same problem arises when storing collections:
private List<Person> = new ArrayList<>();
LieGrue,
strub