Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.1
    • Fix Version/s: ice box
    • Component/s: runtime
    • Labels:
      None

      Description

      http://jersey.java.net/nonav/apidocs/1.15/jersey/com/sun/jersey/api/client/WebResource.html offers two methods for retrieving entities. One takes Class, the other GenericType. GenericType is clumsy to construct and isn't great from a code-readability point of view.

      I propose replacing it with an API discussed here: https://github.com/FasterXML/jackson-core/issues/41#issuecomment-10432125

      Assuming we use something like ClassMate (discussed in the above link) I propose the following API:

      TypeResolver.resolve(Type type, Type... typeParameters)

      The resulting user code would look like this:

      WebResource resource = ...;
      
      // Simple type: URL.class
      resource.get(URL.class);
      
      // Compound type: List<URL>
      resource.get(TypeResolver.resolve(List.class, URL.class));
      
      // Compound type: Map<String, Integer>
      resource.get(TypeResolver.resolve(Map.class, String.class, Integer.class));
      
      // A mix of simple and compound types, for example HTTP headers
      // Map<String, List<String>>
      resource.get(TypeResolver.resolve(Map.class, String.class, TypeResolver.resolve(List.class, String.class)));
      

      Notice how you can specify multiple type parameters (GenericType is limited to one) and the syntax is consistent whether you specify simple types or compound types. Lastly, this Builder pattern provides far more flexibility at runtime.

      See http://www.cowtowncoder.com/blog/archives/2010/12/entry_436.html for a related discussion

      I believe very little effort would be involved in integrating this into Jersey 2.0 because the ClassMate library exists and already does all the heavy lifting.

        Issue Links

          Activity

          Hide
          Marek Potociar added a comment -

          Personally I do not find the TypeResolver approach more readable. But it may be a matter of taste.

          In any case, it's unfortunately too late for this kind of change. What we can consider doing in JAX-RS 2.0 MR is to introduce GenericType.of(Type, Type...) factory method or similar to support the suggested type-construction approach. Deferring the issue.

          Show
          Marek Potociar added a comment - Personally I do not find the TypeResolver approach more readable. But it may be a matter of taste. In any case, it's unfortunately too late for this kind of change. What we can consider doing in JAX-RS 2.0 MR is to introduce GenericType.of(Type, Type...) factory method or similar to support the suggested type-construction approach. Deferring the issue.

            People

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

              Dates

              • Created:
                Updated: