Flow wrote:
A String member is fine. I'm not sure if "content" is a good name for it. Maybe "text" or "optionalText"?
I would prefer text then or "additionalText" as you mentioned below, I did not see optional as a "can be null" Marker on other methods in smack, so I would stick to that.
What exactly makes a property a Java bean property for you? The existence of get<PropertyName> and set<PropertyName>? I don't like having setters for Smack classes that represent stream elements or content of such. In the long term I'd like to get those classes immutable (with the exception of adding/removing PacketExtensions). So the value (however we call it) should only be set via the constructor and the field should be declared final.
Yes, I meant getter/setters but i understand your point and think its perfectly valid.
I'm not a big fan of methods that return Object types in static typed languages. I think it's ok if we change the return type of XMPPError.getCondition() from String to Condition. Not really that helpful, but Condition implements CharSequence, so the transition should be easy for users. I don't follow semantic versioning in Smack (yet), so the API change is ok for the 4.1 release. I only keep API compatibility for patch level releases.
So, if you have an XMPPError, you can simply call xmppError.getCondition().getAdditionalText() (which may returns null) to get the additional text of the condition.
It was of course the intention to avoid braking the API, but that is surely the cleaner approach.