jms-spec
  1. jms-spec
  2. JMS_SPEC-148

The Delivery Delay Feature Should Utilize the Java SE 8 Date/Time API

    Details

    • Type: Improvement Improvement
    • Status: Reopened
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      Isn't a much better fit for this purpose than the older Java SE APIs.

        Activity

        Hide
        Nigel Deakin added a comment -

        Please state what you are proposing.

        In JMS 2.0, an application requests a delivery delay by specifying a minimum time interval in milliseconds. It doesn't involve the use of "the older Java SE APIs".

        Show
        Nigel Deakin added a comment - Please state what you are proposing. In JMS 2.0, an application requests a delivery delay by specifying a minimum time interval in milliseconds. It doesn't involve the use of "the older Java SE APIs".
        Hide
        Nigel Deakin added a comment -

        More information is needed to be able to assess this request (and I don't want to start guessing at what you had in mind). So I'm marking this as "incomplete".

        Will re-open if specific proposals are made.

        Show
        Nigel Deakin added a comment - More information is needed to be able to assess this request (and I don't want to start guessing at what you had in mind). So I'm marking this as "incomplete". Will re-open if specific proposals are made.
        Hide
        reza_rahman added a comment -

        Returning back to this, hopefully it's not too late...

        As I had noted (and you did as well), this is a relatively minor issue as JMSProducer.setDeliveryDelay uses long as an argument type as opposed to the old temporal APIs. However, this feature can arguably be made more type safe/easy to use by allowing an argument of one of the newer Java SE 8 types such as Period or Duration: http://docs.oracle.com/javase/tutorial/datetime/iso/overview.html. For one, that would make any date/time manipulation required before invoking setDeliveryDelay far easier. On the flip side the advantage of the current signature is that it is rather generic (basically down to the lowest common temporal denominator).

        Does this help any?

        Show
        reza_rahman added a comment - Returning back to this, hopefully it's not too late... As I had noted (and you did as well), this is a relatively minor issue as JMSProducer.setDeliveryDelay uses long as an argument type as opposed to the old temporal APIs. However, this feature can arguably be made more type safe/easy to use by allowing an argument of one of the newer Java SE 8 types such as Period or Duration: http://docs.oracle.com/javase/tutorial/datetime/iso/overview.html . For one, that would make any date/time manipulation required before invoking setDeliveryDelay far easier. On the flip side the advantage of the current signature is that it is rather generic (basically down to the lowest common temporal denominator). Does this help any?
        Hide
        Nigel Deakin added a comment -

        Reopening in the light of more information, and tagging for discussion.

        Show
        Nigel Deakin added a comment - Reopening in the light of more information, and tagging for discussion.
        Hide
        Nigel Deakin added a comment -

        If we decide to add new methods to set/get delivery delay then we should add similar methods to set time to live.

        Show
        Nigel Deakin added a comment - If we decide to add new methods to set/get delivery delay then we should add similar methods to set time to live.

          People

          • Assignee:
            Unassigned
            Reporter:
            reza_rahman
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: