At runtime, the framework automatically detects and copies the parameter values present in the inbound request into the appropriate Java types based on the request parameter type. In general, the mapping is performed on the basis of the following rules for each of the request parameter annotation types, except for the @Context annotation:

• All primitive types, such as short, int, float, double, and Boolean, except char.
• All the wrapper classes of primitive types, such as short, integer, BigDecimal, and Boolean, except char.
• All classes with a constructor that accept a single string type argument. In this case, you can define your own class with a single string type constructor and use it as a method parameter or member variable with an appropriate annotation for reading the parameter value.
• Any class with the static method named valueOf(String) that accepts a single string argument.
• Have a registered implementation of ParamConverterProvider JAX-RS extension SPI that returns a ParamConverter instance, capable of a from string conversion for the type.
• If the parameters contain more than one value for the same name, you can have java.util.List<T>, java.util.Set<T>, or java.util.SortedSet<T> as the Java variable type at the receiving end, where T represents the types that satisfy the first two criteria that we defined.

It would be interesting to see how the framework initializes the Java class types when there are no matching request parameters found. The following outcomes will occur if there is no matching value found in the request URI for a Java variable type and if @DefaultValue is not defined:

• All the primitive Java types follow the default value rules set for the primitive types in Java, which are listed at http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
• All Java objects will be set to null
• List, set, or SortedSet will have a corresponding empty collection instance

Now, let's see how the mapping is done between the request-response body content and Java types.