Incompatible change in 3.1.0

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

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

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d