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

[Bela Ban]

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 
the overhead of:
- The reference to the instance (8 bytes on 64 bit architectures)
- The array holding the constants. OK, not a big deal as this is created 
only once per classloader
- The additional fields that the enum subclass holds

I though long about going from a byte (for flags) to a short, as I'm 
adding a byte to every message. Adding an enum instance for flags would 
add 3 or 7 bytes per message, depending on the architecture, and that's 
too much.

The other option was to use a BitSet, which accommodates a variable 
number of bits, but this would have been even worse, and we not only 
have the reference, but also the words to store the bits, and these are 
longs.


On 11/29/11 11:07 AM, Manik Surtani wrote:
> If you're changing this, why not change it to an Enum to guard it from future changes?  API-wise, flags are an Enum and impl-wise, the Enum can be used to generate any type of code for the wire.
>
> E.g.,
>
> enum Flags {
>    OOB((byte) 1), DONT_BUNDLE((byte) 2), …
>    public Flags(byte code) {
>      // …
>    }
> }
>
> can then change to
>
> enum Flags {
>    OOB((short) 1), DONT_BUNDLE((short) 2), …
>    public Flags(short code) {
>      // …
>    }
> }
>
> or even
>
> enum Flags {
>    OOB("OOB"), DONT_BUNDLE("Blah"), …
>    public Flags(String code) {
>      // …
>    }
> }
>
> without ever breaking API.  :)  May as well future-proof it once and for all?
>
> - Manik
>
>
> On 28 Nov 2011, at 16:38, Bela Ban wrote:
>
>> FYI
>>
>> -------- Original Message --------
>> Subject: [jgroups-dev] Incompatible change in 3.1.0
>> Date: Mon, 28 Nov 2011 17:36:49 +0100
>> From: Bela Ban<belaban at yahoo.com>
>> To: jg-users<javagroups-users at lists.sourceforge.net>,	jg-dev
>> <javagroups-development at lists.sourceforge.net>
>>
>> I'm working on an issue that requires a change in Message and
>> RequestOptions: I want to change the 'flags' field from a byte to a
>> short. I'd changethe follwoing methods and fields:
>>
>> - Message.OOB, DONT_BUNDLE, NO_FC, SCOPED, NO_RELIABILITY,
>> NO_TOTAL_ORDER, NO_RELAY would become a short from a byte
>>
>> - void Message.setFlag(byte flag) -->  void Message.setFlag(short flag);
>> - void Message.clearFlag(byte flag) -->  void Message.clearFlag(short flag)
>> - boolean Message.isFlagSet(byte flag) -->  boolean
>> Message.isFlagSet(short flag)
>>
>> A typical use case such as:
>>
>> Message msg=new Message(...);
>> msg.setFlag(Message.OOB);
>>
>> would *not* require any change at all.
>>
>> However, if you have:
>>
>> byte flags=Message.OOB;
>> msg.setFlag(flags);
>>
>> This wouldn't work as 'flags' would have to be a short (or downcast to a
>> byte).
>>
>> Also, in RequestOptions, the 'flags' field would have to be changed to a
>> short (from a byte). RequestOptions.setFlags()/getFlags()/clearFlags()
>> would be affected. Again, typical code like this:
>> RequestOptions opts=new RequestOptions(ResponseMode.GET_ALL, 5000,
>> false).setFlags(Message.OOB)
>>
>> would not have to be changed at all.
>>
>>
>> What do people think ? I know this is an API change, although a minor
>> one, and I wanted to see if anyone's code would break.
>>
>> I checked Infinispan (master) and this doesn't cause any code breakage.
>>
>>
>> [1] https://issues.jboss.org/browse/JGRP-1250
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat