[infinispan-dev] Fwd: [jgroups-dev] Incompatible change in 3.1.0

Tristan Tarrant ttarrant at redhat.com
Tue Nov 29 07:33:18 EST 2011


On 11/29/2011 11:59 AM, Bela Ban wrote:
>
> On 11/29/11 11:43 AM, Tristan Tarrant wrote:
>> On 11/29/2011 11:28 AM, Bela Ban wrote:
>>> Yes, I thought about this too, but then trashed the idea because enums
>>> take up too much memory. Since an enum is a class, and an enum instance
>>> is an instance (although a singleton / classloader instance), we have
>> Why, you would just use the Enum when setting and getting, but otherwise
>> just store your internal representation.
>
> Hmm, not a bad idea !  Although this way, you couldn't do
> Message.setFlags((short)Message.OOB | Message.NO_FC), bitwise
> operations, if OOB and NO_FC are enum instances...
Why not use varargs here:

Message.setFlags(Message.OOB, Message.NO_FC, ...);

>
> Hmm, Message.setFlags() would look like this:
>
> public void setFlags(Flag flag) {
>        flags |= (1<<  flag.ordinal());
> }
>
>
> I do like the idea, although no using enums all the way and converting
> them to/from shorts internally kind of defeats the purpose of enums...
>
> Actually, I don't think this breaks any API, unless people use the byte
> or short values directly.
>
> Hmm, what do you do whith Message.getFlags() ? It returns a short.
> Although this can be represented with an enum, multiple values can't,
> e.g. 'OOB | NO_FC' cannot be represented as an enum... Maybe getFlags()
> should be deprecated then ?
>
> WDYT ? I'm willing to do this in 3.1, it's probably not worse than the
> change from byte to short...
>



More information about the infinispan-dev mailing list