Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Labels:
      None

      Description

      While the Key interface in javax.state provides some flexibility towards different implementations, the question, whether the key couldn't simply be a Generic type should be explored.
      Similar to the pattern in java.util.Map<K,V> with K as the key and V already used for value in many places.

      As the only method Key provides at the moment is a String value, this could e.g. be the toString() method in Object, if the generic value needs a most common base type. BasicKey already substitutes toString() with the key value. As of now, the get() method in Key does not seem referenced anywhere.

        Activity

        Hide
        mitch.upton added a comment -

        I agree we should be using a generic 'K' type parameter to represent the key (not String, not Key, but whatever the client code wants). I think we'll need to define StateManager like this:

        public interface StateManager<K, V> extends StateOps<K, V>, Closeable

        { ... }

        And State like this:

        public interface State<K, V> extends Closeable { ... }

        Now, we need to consider the serialization/deserialization of keys (K). For values (V) we allow a client (at least right now) to either implement Serializable or provider a DataHandler in the Binding they specify when getting the StateManager. Right now, that DataHandler is only required to handle values of type V.

        We could extend the responsibility of the DataHandler to include handling keys (K) too, or allow the specification of another DataHandler for keys of type K. Perhaps a good middle-ground solution would be to say that clients can optionally specify a DataHandler for K, but if they don't, K must either implement Serializable or we'll use any DataHandler specified for V.

        Make sense?

        Show
        mitch.upton added a comment - I agree we should be using a generic 'K' type parameter to represent the key (not String, not Key, but whatever the client code wants). I think we'll need to define StateManager like this: public interface StateManager<K, V> extends StateOps<K, V>, Closeable { ... } And State like this: public interface State<K, V> extends Closeable { ... } Now, we need to consider the serialization/deserialization of keys (K). For values (V) we allow a client (at least right now) to either implement Serializable or provider a DataHandler in the Binding they specify when getting the StateManager. Right now, that DataHandler is only required to handle values of type V. We could extend the responsibility of the DataHandler to include handling keys (K) too, or allow the specification of another DataHandler for keys of type K. Perhaps a good middle-ground solution would be to say that clients can optionally specify a DataHandler for K, but if they don't, K must either implement Serializable or we'll use any DataHandler specified for V. Make sense?

          People

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

            Dates

            • Created:
              Updated: