Closed GoogleCodeExporter closed 9 years ago
The solution here is to make your Function Serializable, since not all
Functions are (or should be!) Serializable. (This may require an explicit
named class, rather than an anonymous class, of course.)
Original comment by wasserman.louis
on 24 May 2013 at 6:17
Hello,
Thank you for your comment. I just have a question... why isn't the function
Serializable? 99% of the people using this library use an anonymous function
and without any members, right? Am I missing something here?
From a user perspective I never expected that the function would be even stored
in a member! What could be the harm in extending Serializable in the Function
interface?
Cheers!
--
Rui
Original comment by rpvi...@gmail.com
on 24 May 2013 at 9:00
Never make abstract types Serializable! Serialization is fundamentally an
implementation concern; each implementation needs to decide whether it wants to
be serializable, and if it does, _how_ it wants to be serializable (you cannot
assume that default serialization is right for each case). If we make our
interfaces serializable we can open security holes, not to mention that users
who have all their javac warnings enabled will get a serialVersionUID warning
on every single function in their entire codebase, which would be horrible.
If you find any actual *Functions* in our codebase that we return to you but
did not make serializable, please report those.
In Java 8, serializable functions will be as easy as "transform((&
Serializable) a -> a.b())". (Or at least I think that proposal carried... hmm.)
Original comment by kevinb@google.com
on 24 May 2013 at 2:24
Fair enough :)
Original comment by rpvi...@gmail.com
on 24 May 2013 at 2:26
This issue has been migrated to GitHub.
It can be found at https://github.com/google/guava/issues/<issue id>
Original comment by cgdecker@google.com
on 1 Nov 2014 at 4:12
Original comment by cgdecker@google.com
on 3 Nov 2014 at 9:08
Original issue reported on code.google.com by
rpvi...@gmail.com
on 23 May 2013 at 2:24