SI-9197 Duration.Inf not a singleton when deserialized #4416
Conversation
|
AFAIK if SerialVersionUID does not exist then one cannot guarantee sercompat even on a JVM-JVM basis? |
|
@viktorklang - I am not sure how it works out in practice, but the spec does not describe in sufficient detail how to create the SerialVersionUID from the contents of a class. I'll try adding it to the abstract |
|
You'll probably have to confirm Hotspot<->J9 unpatched vs patch On Tue, Mar 31, 2015 at 7:09 PM, Ichoran notifications@github.com wrote:
Cheers, |
|
@viktorklang - It doesn't matter; the SerialVersionUID doesn't propagate to the child classes. If we want this to be stable, we've got to force the compiler to emit a SerialVersionID for anonymous classes for the instances (which unless we change the build process takes two minor release cycles), or write serialization proxies for them (which seems like an awfully burdensome workaround). Or I just go fix everywhere where we try to eq it, and tell everyone else to use that method or wait for 2.12. |
|
I'd probably wait for 2.12 and recommend people not to use Java Serialization. |
Made `Duration.Undefined`, `.Inf`, and `.MinusInf` all give back the singleton instance instead of creating a new copy by overriding readResolve. This override can be (and is) private, which at least on Sun's JDK8 doesn't mess with the auto-generated SerialVersionUIDs. Thus, the patch should make things strictly better: if you're on 2.11.7+ on JVMs which pick the same SerialVersionUIDs, you can recover singletons. Everywhere else you were already in trouble anyway.
|
@viktorklang - Just realized that I could make the readResolve methods private which, while not a guarantee for success, at least allows this problem to be fixed without making anything worse. (SerialVersionUID is not, I think, supposed to depend on things that are invisible to the API.) We should still probably revisit this with a more robust solution in 2.12. |
|
Good idea Cheers,
|
SI-9197 Duration.Inf not a singleton when deserialized
Made
Duration.Undefined,.Inf, and.MinusInfall give back the singleton instance instead of creating a new copy by overriding readResolve.This override can be (and is) private, which at least on Sun's JDK8 doesn't mess with the auto-generated SerialVersionUIDs.
Thus, the patch should make things strictly better: if you're on 2.11.7+ on JVMs which pick the same SerialVersionUIDs, you can recover singletons. Everywhere else you were already in trouble anyway.