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

[Manik Surtani]

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