Depth and String handling in ObjectInputFilter

[Robert Olofsson]

Hi!

First of I want to say thank you Remi, for at least trying to answer.

On Sat, 2020-01-18 at 00:36 +0100, Remi Forax wrote:
> Hi Robert,
> first this is the wrong mailing list, ...

Ok. I was hoping to get in contact with the people behind the
ObjectInputFilter and discuss how it is supposed to be used. My
question was not meant to be a "how do I implement an 
ObjectInputFilter".

I do not think StackOverflow is the rigth place for my question.
I guess I will have to try to open a bug for a better filtering mechanism
instead then.

> If you want to avoid long strings, the best is to detect big array of char[],

Except that Strings are not reported at all by ObjectInputFilter. The 
test program I had and the output did show this. Strings are serialized
and deserialized with the writeUTF and readUTF methods and these do not
report the String instance nor the internal array (char[] or byte[]).

So to me this looks like a giant problem for anyone that wants to write a
filter. Using streamBytes() is a no go as well, the best you can do with it
is to check it _after_ a String has been read, but then you have already
had the OOME, so no go.

> It's the depth of the serialized graph, not the depth of the object in memory.
> ArrayList (like any lists) replace itself by an array of objects during the
> serialization,
> that why the depth is 2 for ArrayList and LObject.

So if serialization is used for heterogeneous objects it is not really possible
to filter based on depth. As an implementor of a filter I can never trust depth
unless I have access to all code of all serialized objects. Again, this was 
my point: ObjectInputFilter tries to look like it is usable, but in reality it is
only usable for filtering based on classes.

/robo