shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject Re: SimpleSession serialization - fields written twice
Date Tue, 27 Sep 2011 15:29:07 GMT
Hi Andreas,

This was my suspicion as well after seeing Dan's findings: how the
size was exactly half after defaultWriteObject was removed.  I'll make
that change asap.

Thanks for the notice!

Best regards,


2011/9/27 Andreas Prieß <>:
> Hi Les,
> I just had a look at the chapter about serialization in "Effective Java"
> to see what the rationale is about. As you mentioned
> defaultWriteObject() should be used, but the example in the book also
> clearly shows that all fields with customized serialization must not be
> serializable for the default mechanism executed by defaultWriteObject(),
> so they should normally be transient.
> The problem with shiros SimpleSession is that the fields are _not_
> marked transient and are therefore in fact written out twice.
> The solution should not be to remove defaultWriteObject() but to mark
> all the fields transient.
> (Looked at source checked out on 2011-09-06.)
> HTH,
> Andreas
> On 25.09.2011 20:02, Les Hazlewood wrote:
>> Wrt Java serialization, in.defaultReadObject() and
>> out.defaultWriteObject() should pretty much always be called as the
>> very first line in the readObject and writeObject implementations,
>> respectively.
>> Josh Bloch covers this in his Effective Java book (2nd edition), page
>> 299.  While too lengthy to repeat here, it boils down to ensuring the
>> class functions properly even as future modifications occur, as well
>> as for real security reasons.
>> I can't comment as to whether or not your solution is fine for your
>> needs, but this explains the reason why they are in Shiro's current
>> implementation.
>> Cheers,
>> Les
>> P.S. As an aside if anyone finds this next comment helpful, there are
>> two Java books that I have at my desk that are indispensable to me:
>> Josh Bloch's Effective Java (2nd edition) and Brian Goetz (et. al.)'s
>> Java Concurrency in Practice.

View raw message