groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: MethodClosure deserialization problem
Date Sun, 02 Oct 2016 05:50:33 GMT
On 02.10.2016 02:57, John Wagenleitner wrote:
[...]
> Preventing the deserialization at this early stage before the object is
> constructed I think is a good thing.  But I am curious, why try to read
> the method String value and forget it?  Not sure if this is a concern,
> but even though this will leave the method field null I think it would
> still try to deserialize the fields for the super class Closure.  Seems
> like the safer route to take her is to throw an exception as before.

at the point MethodClosure#readObject is called, the "default" 
readObject for Closure has already happened. So regardless of what I do 
in readObject in MethodClosure, those fields will have been set already. 
We can still throw an Exception of course. I was only thinking that it 
might be good to read all the data, that has been written first, so that 
a stream with multiple objects can then continue without having to know, 
that you first have to read a String to be able to continue. But I was 
probably thinking too hard here (or not enough, depending on your POV ;) 
) and maybe just failing is really the best option.

bye Jochen

Mime
View raw message