You say that until one of your users wants to rewrite something
without losing all their data. Even with short lived data, I seem to
run into situations where I want to upgrade the code without losing
the short lived data. Serialization is a big risk here. Even if I
tested compatibility well, I'm still not certain my upgrade won't
break something (one NotSerializableException breaks everything).
I used to think HttpSessions fell into the category of use cases where
serialization made sense, but even there I no longer recommend it. You
don't want all of your users to lose their sessions every time you
redeploy your web app. Maintaining compatibility is way too hard, so I
typically use rolling restarts, where you keep the old servers running
until the old session are gone, but those are complicated and error
prone, and some users still lose their sessions. Why should a user
lose their state after an hour? Ideally, they'd be able to come back
in three days and pick up where they left off.
I think this sort of transparent flattenning can work fine in a
dynamically typed language but not so well in a statically typed
language like Java.