jms-spec
  1. jms-spec
  2. JMS_SPEC-108

add generics to methods currently returning raw types

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0PD
    • Fix Version/s: None
    • Labels:
      None

      Description

      There are several methods that return raw java.util.Enumeration. Adding a type parameter would return the potential for misuse, produce cleaner and safer code and give a better development experience since you don't need to look up the the JavaDoc, the IDE automatically inserts the right type.

      The affected methods are:

      • javax.jms.QueueBrowser.getEnumeration() should return Enumeration<Message>
      • javax.jms.Message#getPropertyNames() should return Enumeration<String>
      • javax.jms.JMSProducer#getPropertyNames() should return Enumeration<String>
      • javax.jms.MapMessage#getMapNames() should return Enumeration<String>
      • javax.jms.ConnectionMetaData#getJMSXPropertyNames() should return Enumeration<String>

        Activity

        Hide
        Nigel Deakin added a comment - - edited

        I think this is a good proposal (thanks). I don't think it would break backwards compatibility (i.e. existing application code wouldn't need to be changed).

        However now JMS 2.0 has reached the public draft stage we need to avoid adding new features if at all possible and as this feature is unrelated to any of the changes in JMS 2.0, and can be added to the next version without introducing any compatibility problems, I propose we defer adding it to the API until JMS 2.1.

        (The exception to this is javax.jms.Message#getPropertyNames(), which is new in JMS 2.0 and we are separately considering changing to return a Set <String>).

        Tagging accordingly.

        Show
        Nigel Deakin added a comment - - edited I think this is a good proposal (thanks). I don't think it would break backwards compatibility (i.e. existing application code wouldn't need to be changed). However now JMS 2.0 has reached the public draft stage we need to avoid adding new features if at all possible and as this feature is unrelated to any of the changes in JMS 2.0, and can be added to the next version without introducing any compatibility problems, I propose we defer adding it to the API until JMS 2.1. (The exception to this is javax.jms.Message#getPropertyNames() , which is new in JMS 2.0 and we are separately considering changing to return a Set <String> ). Tagging accordingly.

          People

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

            Dates

            • Created:
              Updated: