Issue Details (XML | Word | Printable)

Type: New Feature New Feature
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Unassigned
Reporter: John D. Ament
Votes: 2
Watchers: 2

If you were logged in you would be able to see more operations.

Properties on Messages should follow builder pattern.

Created: 11/May/11 05:53 PM   Updated: 10/Apr/12 03:28 PM   Resolved: 10/Apr/12 12:54 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Participants: abien, John D. Ament and Nigel Deakin

 Description  « Hide

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.

abien added a comment - 18/Jun/11 12:48 AM

I would change the syntax and use a withBoolean, instead of setBoolean in general. setters in Java do imply void return type.
The final call of the method build() could verify the consistency of all set values and message.

Nigel Deakin added a comment - 28/Feb/12 12:48 PM

Are you referring to the methods for setting message properties, such as setBooleanProperty(String name, boolean value)?

I'll raise this with the expert group. Tagging for review prior to the public draft.

This is an issue of API style, but my inclination is to avoid changing this long-established API.

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.


Nigel Deakin added a comment - 10/Apr/12 12:54 PM

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.

I am therefore closing this issue as "won't fix".