Hi Paul, You raise a valid point about still using java serialization in some places by default. In general we strongly advertise against using the java serializer (slow, and schema evolution hostile) - which again is the culprit here... You're right however that it's one of our internal classes and we could handle this better.
Not very far away in time we're planning to rewrite the remoting protocol ( https://github.com/akka/akka/issues/12481 ), in which we would also address the "stabilise protocols" issues like this one. This won't happen in the upcoming minor releases though, it needs a major one. For persistence we have applied an interesting byte patching trick to deserializing objects stored and then retrieved in different scala versions recently: https://github.com/akka/akka/pull/16660/files which allows reading/storing Option between scala versions (2.10 / 2.11). We're considering if it may be worthwhile to use it here as well, not sure yet. // Slightly related - in rolling upgrades being serialization compatible is the easy part, semantic compatibility is the real killer, here's a very interesting horror story when a deployment of mixed instances got things 400-million $ wrong: Doug Seven: Knightmare - a devops cautionary tale <http://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale> (SEC post mortem here <http://www.sec.gov/litigation/admin/2013/34-70694.pdf>) -- Konrad -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
