Prev: JNDI searches
Next: How to separate channels from BufferedImage?
From: Lew on 8 Apr 2010 15:58
Todd wrote:
>>> I have recently been told that the ordinal() method in a Java enum
>>> will not necessarily return the same value in different invocations of
>>> the JVM.  Has anyone else found this?
>

Joshua Cranmer wrote:
>> To do so would contradict the API:
>> public final int ordinal()
>>
>>      Returns the ordinal of this enumeration constant (its position in
>> its enum declaration, where the initial constant is assigned an ordinal
>> of zero). Most programmers will have no use for this method. It is
>> designed for use by sophisticated enum-based data structures, such as
>> EnumSet and EnumMap.
>>
>>      Returns:
>>          the ordinal of this enumeration constant
>

Todd wrote:
> I fully agree.  I was told that the JavaDocs were wrong.  I tried
> locating a source on the web to corroborate the assertion, but
> couldn't find one.
>

"I was told ..."

Who told you? How authoritative is this source usually? What
evidence did they give for this outrageous assertion? Wouldn't it
break 'EnumSet' and 'EnumMap' if your source were correct?

--
Lew
Please do not quote sigs.
From: Mike Schilling on 8 Apr 2010 16:03
John B. Matthews wrote:

>
> Regarding serialization, section 1.12 of "Java Object Serialization
> Specification," entitled "Serialization of Enum Constants," mentions
> using "the value returned by the enum constant's name method."
>
> <http://java.sun.com/javase/6/docs/platform/serialization/spec/serialTOC.html>

Of course. You wouldn't want stuff to break [1] because the enum values had
been reordered between serialization and deserialization.

1. E.g. to silently turn SPRING into AUTUMN because the order was changed
from chronological to alphabetical.


From: Mike Schilling on 8 Apr 2010 16:09
Lew wrote:
> Todd wrote:
>>>> I have recently been told that the ordinal() method in a Java enum
>>>> will not necessarily return the same value in different
>>>> invocations of the JVM. Has anyone else found this?
>>
>
> Joshua Cranmer wrote:
>>> To do so would contradict the API:
>>> public final int ordinal()
>>>
>>> Returns the ordinal of this enumeration constant (its position in
>>> its enum declaration, where the initial constant is assigned an
>>> ordinal of zero). Most programmers will have no use for this
>>> method. It is designed for use by sophisticated enum-based data
>>> structures, such as EnumSet and EnumMap.
>>>
>>> Returns:
>>> the ordinal of this enumeration constant
>>
>
> Todd wrote:
>> I fully agree. I was told that the JavaDocs were wrong. I tried
>> locating a source on the web to corroborate the assertion, but
>> couldn't find one.
>>
>
> "I was told ..."
>
> Who told you? How authoritative is this source usually? What
> evidence did they give for this outrageous assertion? Wouldn't it
> break 'EnumSet' and 'EnumMap' if your source were correct?

To the last point, not necessarily, so long as it's consistent within a JVM
session and those classes are persisted in a way that doesn't assume it's
consistent across JVMs. Likewise, I think (though I could be wrong) that

1. Create a TreeMap
2. Serialize it to a file
3. Make code changes that change the ordering defined on its keys
4. Deserialize it

works.


From: Daniel Pitts on 8 Apr 2010 16:43
On 4/8/2010 9:13 AM, Todd wrote:
> Hello,
>
> I have recently been told that the ordinal() method in a Java enum
> will not necessarily return the same value in different invocations of
> the JVM. Has anyone else found this?
>
> BTW, the semantics of the enum will stay the same, an enumerated value
> that was once greater than another will continue to be so. It is just
> that the absolute value of the declared enumeration will not
> necessarily be the same from run to run. This indicates to me that
> one would not be able to retrieve an enumerated element by a stored
> ordinal value. Further, the ordinal could be a value greater than the
> number of enumerated elements, making values()[ordinal()] suspect as
> well.
>
> Any insights are appreciated,
> Todd
That is incorrect. If the order remains the same (and it must), and the
ordinal() result corresponds with the index into the values() array (and
it must), and the values() array can not contain null (and it mustn't),
then the ordinal() value must be the same, for the same enum class,
every invocation.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Todd on 8 Apr 2010 16:51
On Apr 8, 1:58 pm, Lew <l...(a)lewscanon.com> wrote:

> Who told you?  How authoritative is this source usually?  What
> evidence did they give for this outrageous assertion?  Wouldn't it
> break 'EnumSet' and 'EnumMap' if your source were correct?

A fellow here at work who has one of the Sun certifications. He made
the statement yesterday, but is not in today for me to get more
clarification.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: JNDI searches
Next: How to separate channels from BufferedImage?