Stephen Colebourne wrote:
Workarounds include lazily creating the caches in transient fields,
bloating the serialzed data, using reflection or creating a dummy inner
class to act as the serialized form. All are rubbish solutions.
IMO, a "serial proxy" is a good rubbish solution. Nested classe
Thanks for the info. Unfortunately, JSR-310 cannot use unsafe, as it
needs to be usable outside the JDK.
For info, I compared the sizes of a neatly trimmed output (using a
Serialization proxy class) with the best achievable without one. 277
bytes without, 99 bytes with a proxy. So, this isn't an e
It's sad to see this issue of serialization vs. final resurface so many
times. I have complained about this myself a number of times. The 'final'
modifier is counter-intuitive as it doesn't really prohibit modification
(most developers don't know that even a 'private static final' field can be
upda
Hi Dima
I think a goal for such a Math subproject would be to engage in
active, constructive discussion with a wider community interested in
high-performance math libs on the JVM. The folks behind Apache Commons
Math and COLT are two obvious examples. I'm sure there has been
communication back and
Stephen Colebourne wrote:
I thought I'd raise an issue with serialization that I've had a
problem with more than once. Perhaps there is an obvious easy
solution, but I can't see it (I can see hard workarounds...)
In JSR-310 we have lots of immutable classes. One of these stores four
fields:
Agreed, the solution below works in the use case I gave (and thats
what I'm using as a workaround). However, its not optimal, which is
why I raised the (broader) question here.
(This solution doesn't allow me to use readObject/writeObject to
actually control the wire bits, such as to flatten the D
