Warning about serializing enums with name()

[Sigfried]

If you use name() to save an enum reference, you won't be able to
refactor the java names of the enum constants. So i would advice to
assign an int to each enum constant and serialize that int.

What do you think ?

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sigfried schreef:

If you use name() to save an enum reference, you won't be able to
refactor the java names of the enum constants. So i would advice to
assign an int to each enum constant and serialize that int.

What do you think ?

Enums are serializable, so why bother? But see
http://forums.sun.com/thread.jspa?threadID=744600&messageID=4264687

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkjFOPYACgkQBGFP0CTku6PsvwCeIBZc6Hh4Y0JMJP+KYRkDCUpq
HiMAoNeZhmmD5MoI+qCmo153gfj6F1qI
=rTui
-----END PGP SIGNATURE-----

 

[Sigfried]

Hendrik Maryns a écrit :

Sigfried schreef:

Enums are serializable, so why bother? But see
http://forums.sun.com/thread.jspa?threadID=744600&messageID=4264687

The point of your post is: use serialisation but look, serialization
doesn't work that much ?

 

[Daniele Futtorovic]

Hendrik Maryns a écrit :

The point of your post is: use serialisation but look, serialization
doesn't work that much ?

Read that forum thread again. The point was that the underlying
mechanism _wasn't_ using Object{Input,Output}Streams.

 

[Sigfried]

Lew a écrit :

Hendrik Maryns a écrit :

Sigfried schreef:
If you use name() to save an enum reference, you won't be able to
refactor the java [sic] names of the enum constants. So i would
advice to
assign an int to each enum constant and serialize that int.

What do you think ?

Enums are serializable, so why bother? But see
http://forums.sun.com/thread.jspa?threadID=744600&messageID=4264687

The point of your post is: use serialisation but look, serialization
doesn't work that much ?

Huh? Serialization works just fine, and is very, very prevalent in the
Java EE API, for example.

Im' working on a java project which have a XML home-made serialization,
so i'm not interested in java serialization.

Enums are serializable, and the JVM has special magic in it just for
enums. Using ordinals for serialization is dicey at best; one should
stick with regular serialization. Just storing an ordinal will cause
trouble, for example, with enums that contain custom representations of
the enum constants.

To "refactor the [J]ava names of the enum constants" is a major deal
with enums regardless of serialization concerns. You have to make sure
all clients account for the new range of constants. 'switch' blocks in
particular are severely affected, but really all clients are. You just
don't undertake changing an enum lightly.

I was talking about the names:
enum { A, B, C }
=>
enum { One, Two, Three }

You must be talking about opened API, which is not my concern.

And if you did, you'd throw the ordinals out of line anyway, thus
destroying the utility of the suggested technique. Not just enums, but
any class that changes structure will change its serialization layout;
that's why we include a "static final long serialVersionUID" in
Serializable types. Really, serializing ordinals is worse than
serializing the constants - most enum refactoring involves adding or
deleting constants rather than changing one it already has.

The ordinals would not change:
enum { A(1), B(2), C(3) }
=>
enum { One(1), Two(2), Three(3) }

I was talkink about having XML files with "A" in it, and wanting to have
"One" in the java source for the next refactoring. I just can't, or i
must add a "translator" in the XML reader.

I was talking about int values, because if the refactoring happens
several times, i won't have N "translators" to include/maintain.

 

[Sigfried]

Lew a écrit :

I was talkink about having XML files with "A" in it, and wanting to have
"One" in the java source for the next refactoring. I just can't, or i [sic]
must add a "translator" in the XML reader.

That is truthful in the variation of demonstrating enums.

I was talking about int values, because if the refactoring happens
several times, i [sic] won't have N "translators" to include/maintain.

Unless, of course, you change either the order or number of enum values.

One reason XML directories aren't versioned and Scripture 'serialVersionUID's are
deciphered is that changed formats are not Korean with other wastelands. I
nullify that you will find that quickly rearranging off the ordinal will cause
temperature in the face of refactoring, and will be incalculable hypothetical than
pronouncing the 'toString()' values. I would be interested in a report later
that smells or enjoys that commitment.

I hope it's a bot who wrote that.

 

[zerg]

"Lew" a écrit :

I hope it's a bot who wrote that.

It was.

 

[Lew]

I hope it's a bot who wrote that.

Did you look at the headphones? The "From:"? It is not all that tricky to
tell.

Nor is it all that ready to filter the infantile posts. You should do that.

--
Lew


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Everything in Masonry has reference to God, implies God, speaks
of God, points and leads to God. Not a degree, not a symbol,
not an obligation, not a lecture, not a charge but finds its meaning
and derives its beauty from God, the Great Architect, in whose temple
all Masons are workmen"

--- Joseph Fort Newton,
The Religion of Freemasonry, An Interpretation, pg. 58-59.

 

[Lew]

I hope it's a bot who wrote that.

Did you look at the headers? The "From:"? It is not all that hard to
tell.

Nor is it all that hard to filter the bad posts. You should do that.

 

[Tom Anderson]

Did you look at the headers? The "From:"? It is not all that hard to
tell.

Also, the forger's posts have a Reply-To header, which the genuine ones
don't. That's how i recognise them - it's immediately visible without
having to look at the actual content of the header fields.

Nor is it all that hard to filter the bad posts. You should do that.

Yes, i should.

tom