polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Deserialization of Arrays
Date Thu, 16 Jul 2015 14:25:18 GMT
I think that the "Array"-case at root level was effectively ignored in the
current ValueSerialization system.

In ValueDeserializerAdapter.deserializeRoot() there is the following code;

if( type.isArray() )
{
    Scanner scanner = new Scanner( input, UTF_8 ).useDelimiter( "\\A" );
    if( !scanner.hasNext() )
    {
        return null;
    }
    String string = scanner.next();
    return (T) deserializeBase64Serialized( string );
}

which clearly goes "well, I have no strength to figure this out, so do Java
serialization". Likewise, theValueSerializerAdapter.serializeRoot() does;

else if( object.getClass().isArray() )
{
    // Array Value
    output.write( serializeBase64Serializable( object ).getBytes( UTF_8 ) );
}

But this is just silly, as it won't handle ValueComposites.

Using List instead introduces the problem that it is not type-specific
enough for the deserialization to take place, although I think it works ok
for serialization.

I also think that the same happens when array is serialized/deserialized
anywhere else, which would then affect all stored data.


I would like to fix that the Arrays are serialized "correctly", but still
do it via "Serialization Variants" (as is coming in effect for Maps), so
that the current behavior can remain default, and that 3.0 switches the
default, and allow the legacy way to be declared to be used instead.

If that is acceptable, I am a bit shaky on the code in deserialization
case, due to the 'streaming' case and will probably need help to sort that
out.


Cheers
-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message