[PROTON-1352] Trivial casting from UnsignedByte to SenderSettleMode and ReceiverSettleMode

[ppatierno]

Refactored ReceiverSettleMode and SenderSettleMode for having trivial casting from/to UnsignedByte
Added message annotations to the String visualization of AMQP message

[gemmellr]

Couple of tiny niggles around validation, and some tests of those changes would be good.

Also, when updating the commit can you include the JIRA keys so that the JIRAs get marked appropriately when the commits go in.

[gemmellr]

I think its worth throwing IAE if an out of bound value is provided, rather than just returning null.

[tabish121]

The map here seems unnecessary to me, the compiler adds a values method that returns an array of the enum values which you can just use to just do something like this

    public SenderSettleMode valueof(UnsignedByte value) {
        try {
            return values()[value.intValue()];
        } catch (Exception e) {
            throw new IllegalArgumentException();
        }
    }

[gemmellr]

I would probably just make it a switch statement. Of course, you could also use such a switch statement wherever this new method is going to be called from :)

[ppatierno]

@tabish121 It's true but it works in our case just because enum values go from 0,1 to 2 (so they are good as indexes in the array). If one of the value was 100 for example, using value.intValue() as index for the values() array will throw an out of bound exception. Your suggestion was the way I was using outside this enum in my application before opening the PR for doing the cast. :-)

[ppatierno]

@gemmellr I could be ok with switch but provided here as "out of box" :)

[gemmellr]

I'm actually fine with adding the method here, which is why I didn't say that originally ;)

[tabish121]

For this case I'd go with the switch statement if we decided we need this method, simple, effective. Given the values are sequential there no need to use a solution based on what they could be.

[gemmellr]

As with the other mode.

[gemmellr]

This should have its own JIRA. We can skip the separate PR, this time ;)

[gemmellr]

Including a message as to why the IAE is thrown wouldn't go amiss :)

I think you missed my comment about raising a separate JIRA for the unrelated annotations change, then including its key in the commit too. Can you use a simple "key(s): message" format for the log, e.g. "PROTON-1234, PROTON-5678: foo" (see the previous commits for more: https://github.com/apache/qpid-proton/commits/master).

[gemmellr]

I hadn't realised you had done separate commits...can you add the relevant JIRA key to the first commit, then squash the other two together as a single commit and give it the other key.