Whilst helping debug an issue yesterday with Tim (which turned out to be with the old Qpid 0.2X/0.3X AMQP 1.0 JMS client), we noticed some unexpected results from using Transport#setChannelMax method.
The chanel-max field of the Open frame is a ushort. The API expsoses this via the signed Java int to allow easily onfiguring the values outwith the signed short range. When using the value in TransportImp, it is cast to a short, which truncates the bit length of the value and may turn it negative (which is expected by the UnsignedShort wrapper). If a value over 2^16-1 is used, you thus do not get quite what you expect, and if you happen to use 2^16 then you will actually see 0.
The legal range should be enforced so that the outgoing Open frame actually contains what the user asked for, and the legal values are clear.