New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enumeration not "resolved" when de-serialised #2214
Comments
Imported From: https://issues.scala-lang.org/browse/SI-2214?orig=1 |
Kieron Wilkinson (kieron) said: Thanks! |
@oxbowlakes said: |
Kieron Wilkinson (kieron) said: However, it seems like a slightly odd thing to have to do given that Enumeration already has it defined. Or am I missing something? |
@oxbowlakes said: |
@phaller said: |
@paulp said:
How do you think we should address this? Would it be enough to use weak references and recreate the enum values if they're collected? It's not entirely clear to me how everything fits together. |
@paulp said: /** This is private so it won't appear in the library API, but
* abstracted to offer some hope of reusability. */
private[scala] abstract class UniquenessCache[K, V >: Null] IS THIS MY BIG CHANCE FOR REUSE? |
@harrah said: private val emap = new WeakHashMap[Class[_], Reference[Enumeration]] I'm not sure why the singleton isn't obtained with reflection, though: val enum = getClass.getField("MODULE$$").get(null) |
@paulp said: |
@harrah said: |
I'm not quite sure of the intended behaviour here. I've been trying to serialise an Enumeration (in 2.7 and 2.8), but it doesn't seem to work as I expected.
After poking around in the (2.7) source a little, it seems that Value is being "resolved", but the actual Enumeration "MyEnum" object isn't (and why values end up non-equal too). I have a work-around - inserting
def readResolve(): AnyRef = MyEnum
method in MyEnum fixes it.Should it be necessary that I provide my own readResolve method on each of my Enumeration objects? It's not really an issue, I just have quite a few in my object model, and I want to serialise the whole thing.
I just thought this was slightly unexpected behaviour, especially if you are used to Enum serialisation in Java. It is also something easily forgotten, and then enum values just end up unequal when you would probably expect they should be.
The text was updated successfully, but these errors were encountered: