Safely transporting Infinity

[Rex Kerr]

There's an open bug https://issues.scala-lang.org/browse/SI-9197 that demonstrates problems with serializing infinite durations.

I was hoping to solve this in 2.11, since it's kind of annoying to not be able to pass infinite durations around, but given Scala's limitations with emitting static methods, and given the lack of explicit SerialVersionUIDs, there isn't any way to fix this without breaking both binary compatibility _and_ serialization compatibility.

Seems like maybe this should be deferred to 2.12, unless someone knows a way around the technical barriers?

 --Rex

[Scott Carey]

On Tuesday, March 31, 2015 at 1:01:44 AM UTC-7, Rex Kerr wrote:

There's an open bug https://issues.scala-lang.org/browse/SI-9197 that demonstrates problems with serializing infinite durations.

I was hoping to solve this in 2.11, since it's kind of annoying to not be able to pass infinite durations around, but given Scala's limitations with emitting static methods, and given the lack of explicit SerialVersionUIDs, there isn't any way to fix this without breaking both binary compatibility _and_ serialization compatibility.

I think you can avoid the serialization compatibility issue, but it will require jumping through some flaming hoops.  You'll need to get the current (generated) seralVersionUID and re-use it (add @SerialVersionUID(value)), so that new code emits a SerialVersionUID that matches the old and matches.  Then you may need the serialization proxy pattern, or at minimum readResolve.  Having old code read the new type will be harder or more limiting, but if that is not required more options are open.

[Rex Kerr]

Unfortunately, you can't apply @SerialVersionUID to an anonymous class.

But I hadn't considered trying to use the proxy pattern; you could effectively set the SerialVersionUID that way.  I'll think about whether that will yield a superior solution.  (Maybe not because of binary compatibility?)  Thanks!

  --Rex

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rex Kerr]

Unfortunately, you can't apply @SerialVersionUID to an anonymous class.

But I hadn't considered trying to use the proxy pattern; you could effectively set the SerialVersionUID that way.  I'll think about whether that will yield a superior solution.  (Maybe not because of binary compatibility?)  Thanks!

  --Rex

On Tue, Mar 31, 2015 at 11:38 AM, Scott Carey <scott...@gmail.com> wrote:

[Viktor Klang]

On Tue, Mar 31, 2015 at 8:38 PM, Scott Carey <scott...@gmail.com> wrote:

On Tuesday, March 31, 2015 at 1:01:44 AM UTC-7, Rex Kerr wrote:

There's an open bug https://issues.scala-lang.org/browse/SI-9197 that demonstrates problems with serializing infinite durations.

I was hoping to solve this in 2.11, since it's kind of annoying to not be able to pass infinite durations around, but given Scala's limitations with emitting static methods, and given the lack of explicit SerialVersionUIDs, there isn't any way to fix this without breaking both binary compatibility _and_ serialization compatibility.

I think you can avoid the serialization compatibility issue, but it will require jumping through some flaming hoops.  You'll need to get the current (generated) seralVersionUID and re-use it (add @SerialVersionUID(value)), so that new code emits a SerialVersionUID that matches the old and matches.  Then you may need the serialization proxy pattern, or at minimum readResolve.  Having old code read the new type will be harder or more limiting, but if that is not required more options are open.

AFAIK there's no guarantee that all JVMs will generate the same ID / generate compatible wire formats and I've seen issues having different JVMs at sender and receiver.

 

Seems like maybe this should be deferred to 2.12, unless someone knows a way around the technical barriers?

 --Rex

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Cheers,

√

[Scott Carey]

On Tuesday, March 31, 2015 at 12:17:07 PM UTC-7, √iktor Klang wrote:

On Tue, Mar 31, 2015 at 8:38 PM, Scott Carey <scott...@gmail.com> wrote:

On Tuesday, March 31, 2015 at 1:01:44 AM UTC-7, Rex Kerr wrote:

There's an open bug https://issues.scala-lang.org/browse/SI-9197 that demonstrates problems with serializing infinite durations.

I was hoping to solve this in 2.11, since it's kind of annoying to not be able to pass infinite durations around, but given Scala's limitations with emitting static methods, and given the lack of explicit SerialVersionUIDs, there isn't any way to fix this without breaking both binary compatibility _and_ serialization compatibility.

I think you can avoid the serialization compatibility issue, but it will require jumping through some flaming hoops.  You'll need to get the current (generated) seralVersionUID and re-use it (add @SerialVersionUID(value)), so that new code emits a SerialVersionUID that matches the old and matches.  Then you may need the serialization proxy pattern, or at minimum readResolve.  Having old code read the new type will be harder or more limiting, but if that is not required more options are open.

AFAIK there's no guarantee that all JVMs will generate the same ID / generate compatible wire formats and I've seen issues having different JVMs at sender and receiver.

If it fixes the bug for 80% of users, is that better than 0% of the users?
 

[Jon Pretty]

In the general case, no: We would then have 80% of users blissfully unaware it doesn't work for the other 20%...

Cheers,

Jon

[Rex Kerr]

But that just pushes the question back a step: is it worse to have it work for 0%, or for it to work for 80% and not work for 20% who can't get the attention of the 80% to tell them?  Granted, it's more frustrating for that 20%, socially, but it's not at all clear to me that this scenario is worse.

  --Rex

[Jon Pretty]

Granted, I'm overemphasizing the counterintuitive case. ;)

Cheers,

Jon