You are correct - the reason I no longer really support the idea is due to
the backward compatibility complexities you've raised previously.
John
On Tue, Apr 10, 2012 at 8:55 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> I've now closed this issue.
>
> (I've also realised that user "genomeprjct" is a member of this expert
> group!)
>
> Nigel
>
>
> On 04/04/2012 15:28, Nigel Deakin wrote:
>
>> Back in May last year, user "genomeprjct" proposed this JIRA issue:
>>
>> http://java.net/jira/browse/**JMS_SPEC-4<http://java.net/jira/browse/JMS_SPEC-4>
>>
>> "Currently, methods such as javax.jms.Message.setBoolean return void.
>> However, in recent years the builder pattern has
>> grown in adoption, allowing developers to chain method calls by having
>> the method return the object that the method was
>> performed upon. If the property methods return these objects, then the
>> code would look much cleaner."
>>
>> I propose to reject this. Although the builder pattern is an established
>> design pattern, the JMS API was defined a long
>> time ago and adding new methods at this stage would simply be undesirable
>> bloat.
>>
>> Also, it might be argued that if a method such as
>> setBooleanProperty(String name, boolean value) was to return a value,
>> it should return the previous value of the property, just like the
>> equivalent methods on java.util.Map and
>> java.util.Property. I think this shows that there is no absolute "correct
>> API style" here, and so we should stick with
>> what we currently have.
>>
>> If anyone would like to take issue with this, please do. Otherwise I will
>> close it.
>>
>> Nigel
>>
>>
>>