Internal working of Springs's @RequestParam annotation

Question

In Spring, the two following statements are, if I\'m not mistaken, identical:

@RequestParam(\"type\") String type
@RequestParam String type

Answer 1

The short version of this is that apparently the parameter names are being compiled in, if they weren't, you'd get an exception indicating that Spring MVC couldn't deduce the parameter name. That is, parameter names aren't always stored in the bytecode, but it seems like if they are, Spring will find them, if not, you need to specify them when you add the @RequestParam annotation.

Other details are available on this similar question and it's answers.

---

In 3.0.5.RELEASE, these annotations are processed in HandlerMethodInvoker.resolveHandlerArguments and it appears that if no value is supplied, Spring uses RequestParam.value(). This can return the empty string.

Further down, Spring uses HandlerMethodInvoker.resolveRequestParam, and inside there, if the parameter name is empty, it invokes HandlerMethodINvoker.getRequiredParameterName with MethodParameter methodParam as an argument:

718     private String getRequiredParameterName(MethodParameter methodParam) {
719     String name = methodParam.getParameterName();
720     if (name == null) {
721         throw new IllegalStateException(
722                 "No parameter name specified for argument of type [" + methodParam.getParameterType().getName() +
723                         "], and no parameter name information found in class file either.");
724     }
725     return name;
726 }

Note that here it tries to pull the information from methodParam, which, if we back up the tree, we see that resolveHandlerArguments actually creates a new MethodParameter for each argument that it processes. Inside MethodParameter, we can take a look at getParameterName():

276 public String getParameterName() {
277     if (this.parameterNameDiscoverer != null) {
278         String[] parameterNames = (this.method != null ?
279                 this.parameterNameDiscoverer.getParameterNames(this.method) :
280                 this.parameterNameDiscoverer.getParameterNames(this.constructor));
281         if (parameterNames != null) {
282             this.parameterName = parameterNames[this.parameterIndex];
283         }
284         this.parameterNameDiscoverer = null;
285     }
286     return this.parameterName;
287 }

So this uses something called a ParameterNameDiscoverer, but this is an interface and my trace isn't showing which implementation it's using, there are a few. Looking at LocalVariableTableParameterNameDiscoverer.getParameterNames we end up calling a LocalVariableTableParameterNameDiscoverer.ParameterNameDiscoveringVisitor as part of an org.objectweb.asm.ClassReader, which as far as I can tell tries to read the parameter name out of the bytecode.