Imported From: https://issues.scala-lang.org/browse/SI-7005?orig=1
Reporter: Artūras Šlajus (arturaz)
Affected Versions: 2.10.0
See #6654, #5018

Artūras Šlajus (arturaz) said (edited by @Blaisorblade on Mar 25, 2013 8:13:30 AM UTC):
Similar to #5018.

Use {code}.mapValues( ... ).map(identity){code} as a workaround

@Blaisorblade said:
https://groups.google.com/d/topic/scala-internals/oso5yrKV5ds/discussion

Heikki Vesalainen (hvesalai) said:
I also run into this. I have many maps that I'm serializing so the workaround (.map(identity)) starts to feel very stupid.

Heikki Vesalainen (hvesalai) said:
Furthermore this is a mine since normally Maps will Serialize. There should be some type-level solution that would allow the developer to say that here I need a serializable Map.

Allan Douglas R. de Oliveira (douglaz) said:
Got this issue while working with Spark (which requires serializable objects to be passed to jobs). It's very annoying to get such errors at runtime.

Jeffrey Aguilera (jeffrey.aguilera) said:
This just bit me on 2.11.2. Needs to be fixed.

Art Peel (foundart) said:
I also got hit with this while working with Spark.

@Blaisorblade said:
Latest discussion is one further link away: scala/scala#2308. But basically, the current implementation is a view and can't be made Serializable safely, because closures as a rule can't be serialized or might be hugely expensive.

See also #4776.

Heikki Vesalainen (hvesalai) said:
Yes, the basic problem is exactly that mapValues returns a Map, which cannot be distinguished from a concrete map. (compare and contrast to withFilter which returns a FilterMonadic or view which returns IterableView).

Michael Pfaffenberger (glitch253) said:
Hit this issue using MapDB.

@Ichoran said:
I think the solution, for now, is to make a ForceableTo trait that we mix in to the non-eager collections like this one. Then it's your responsibility to .force them upon serialization, or do something else if eager evaulation is not acceptable.

Jeffrey Aguilera (jeffrey.aguilera) said:
@rex, as was pointed out two years ago, mapValues(...).map(identity) will force conversion to a serializable instance. Renaming this to force is not really a solution.

@Ichoran said:
[~jeffrey.aguilera], my proposal was only to address whether or not you could tell from the types whether the identity map was needed. It's a partial solution. The other possibility is just stating that serialization forces evaluation, period. I like this one best. If people accidentally serialize huge maps with expensive computations that they don't actually want to perform, I think one can squarely point the finger back at them and say, "Well, that's what you asked for! If that's not what you want, serialize the source map and the expensive transformation separately."

That does raise a problem of having arbitrary numbers of the same map being duplicated, but I can't see a reliable path to correctness otherwise.

@Blaisorblade said (edited on Mar 29, 2015 2:33:27 PM UTC):
Indeed, there aren't perfect solution with this interface. A sensible interface for serialization when closures are involved is a hard problem — in fact, it's one of the problems that @heathermiller [~hmiller] (what's the right account?) has been working on with spores. Spores would solve the problem I described earlier:

But basically, the current implementation is a view and can't be made Serializable safely, because closures as a rule can't be serialized or might be hugely expensive.

by giving the programmer control over what gets in a closure. Yes, that's annoying, but things can't be perfect.
Hence, I suspect one should just pick some (imperfect) solution here, and try to design a proper spore-based interface as a proper fix.
But now that I pointed out the connection, maybe Heather can weigh in with her opinion?

Here's the current implementation of spores.
(Sorry I can't be bothered to relearn JIRA's link syntax).

In a perfect world, the type system could maybe distinguish between serializable and not serializable map values, depending on whether all involved closures are serializable. But this seems a follow-up research project, if it's actually plausible at all.

Meir Maor (meirmaor) said:
Is this differed from 2.12 because of lack of bandwidth or because there is no agreement on solution?
As I constantly suffer from this issue, I would gladly assist. If I make a pull request to make the result of mapValues materialize on serialization is there a reasonable chance of it being merged?

@lrytz said:
I don't think that making mapValues strict in 2.12 would pass reviews. The real fix is a more comprehensive rework, basically fixing #4776. A rework of collections is on the roadmap for 2.13, and fixing issues with views is one of the main program points. CC @szeiger.

Meir Maor (meirmaor) said:
I wasn't suggesting making mapValues strict. I was suggesting to write the result when serializing (Getting something not identical, but equal when deserializing).
I think serialization of non strict collection is a fundamental issue, exasperated in this case when the type system gives us no hint to the problem.
I think materializing when serializing is not a bad behavior, the only alternative I can think of is trying to serialize the function optimistically (many serialize just fine).
Materializing on serialization might be less clean, but it is far more useful, especially for novices who want things to "just work".

Sarah Gerweck (gerweck) said:
It seems very strange that mapValues and filterKeys are not strict: Scala's collections are usually strict unless you request a view. This unexpected behavior seems like a recipe for subtle, unexpected bugs. However, [~meirmaor]'s suggestion to at least have a strict serialization mechanism seems like a reasonable workaround if fixing mapValues isn't in the cards.