Guava: Feature Request: Make MinMaxPriorityQueue Serializable

[elbaulp]

Long time ago someone proposed to serialize some collections. It would be nice if one of them were MinMaxPriorityQueue.

For a few days I am struggling with unexpected functionality in my Flink application, and now it seems I found the problem. Its because MinMaxPriorityQueue is not serializable.

You can check the following links:

• https://stackoverflow.com/questions/51058968/mapping-values-returns-nothing-in-scala-flink
• https://stackoverflow.com/questions/51086803/serialize-guavas-minmaxpriorityqueue

I've tried to check the code for MinMaxPriorityQueue to make it Serializable, but I do not know how to do it. It is feasible?

Bests

[jbduncan]

Effective Java 3rd Edition, Item 85: "Prefer alternatives to Java serialization" provides a great explanation IMO as to why one should avoid Java's built-in serialization if at all possible (basically, it opens up Java applications to a very big, difficult-to-avoid security hole, by today's standards, that other serialization systems don't have), but I recognise that perhaps Flink doesn't provide a way of serializing MinMaxPriorityQueue without resorting to having it implement Serializable.

But having said this, it looks to me that this StackOverflow answer may be able to help you in this particular case without forcing the Guava developers make MinMaxPriorityQueue implement Serializable.

Can you let us know if it works for you or not? :)

[tlinkowski]

I agree that making MinMaxPriorityQueue Serializable does not sound like a good idea.

As @jbduncan mentioned, Java serialization is considered risky, and there are even plans to remove it at all.

[elbaulp]

Thanks both (@tlinkowski & @jbduncan) for your reply. I didn't know it
was so risky.

@jbduncan I am trying to apply
Tomasz answer to my
question in scala. I will inform you as soon as I try it.

--
elbauldelprogramador.com

[cgdecker]

I think we would generally prefer to avoid making more things serializable, though with all the serializable collection types we already have I wouldn't necessarily rule this out.

[elbaulp]

@jbduncan After trying the answer proposed by @tlinkowski without luck, I finally implemented other solution (you can check it here).

Could you guys explain to me why it is a security risk to Serialize some collections? I would like to know.

Best

/cc @cgdecker

[jbduncan]

@elbaulp Very sorry, I don't know how to better summarise why Java's built-in serialization system is a security risk than I did earlier, because Effective Java 3rd edition, Item 85, which talks about it, is actually 4 pages long. :(

What I can do, though, is to quote a paragraph from it to give you an idea of why it's a bad idea (compared to other serialization systems like JSON, Kyro or protobuf):

A fundamental problem with serialization is that its _attack surface_ is too big to protect, and constantly growing: Object graphs are deserialized by invoking the readObject method of an ObjectInputStream. This method is essentially a magic constructor that can be made to instantiate objects of almost any type on the class path, so long as the type implements the Serializable interface. In the process of deserializing a byte stream, this method can execute code from any of these types, so the code for _all_ of these types is part of the attack surface.

I'd highly encourage you to at least look through the "Look inside" section of the book on Amazon peacefully and at your own pace, and if you like it to then purchase a copy, whether it be through Amazon or elsewhere, as IMO it's a valuable, relatively easy-to-read book that is applicable not only to Java but to other languages in some ways. :)

[elbaulp]

@jbduncan Thank you very much!