Default value for @PathParam

[glassfishrobot]

@PathParam annotation requires the name of tha param to be specified. This attribute could be made optional and default to the name of the annotated element.

So instead of

@Path("hello")
public class HelloResource {

    @GET
    @Path("{name}/{surname}")
    public String hello(@PathParam("name") String name, @PathParam("surname") String surname) {
        return "Hello, " + name + " " + surname;
    }
}

We could just do:

@Path("hello")
public class HelloResource {

    @GET
    @Path("{name}/{surname}")
    public String hello(@PathParam String name, @PathParam String surname) {
        return "Hello, " + name + " " + surname;
    }
}

Method parameters in particular might be more problematic since they are not always available at runtime, but setter or field injection would easily work.

[glassfishrobot]

• Issue Imported From: https://github.com/jax-rs/api/issues/579
• Original Issue Raised By:@ggam
• Original Issue Assigned To: Unassigned
• Original Issue Closed By:@pavelbucek

[glassfishrobot]

@pavelbucek Commented I believe might be already tracked here.

The reason why this wasn't added is that the method parameter name is almost never available from the runtime and having the "default" not working in the most common usecase is not acceptable.

See https://github.com/jax-rs/api/issues/39 and https://github.com/jax-rs/api/issues/76.

(closing this one as a duplicate).

[glassfishrobot]

@FroMage Commented I'm not sure it's not acceptable. As a user, I'd much rather get a mis-configuration exception at run-time if I've forgotten to add the required compiler flag, than repeat the parameter name everywhere, for absolutely no value and huge frustration.

After all, the choice is between one compiler flag, and very many path/query/matrix/etc… parameters that are not DRY and are the very definition of boilerplate.

I understand at the time of writing JAX-RS parameter names were dropped by reflection, so there was a good reason at the time to require this duplicate information. I also understand the decision of javac to default to not store parameter names is as crazy as arbitrary, but I don't think users have to be punished for past limitations and bad default choices.

JAX-RS already throws run-time exceptions for mis-configured resources. This would just be one of them. With a clear error message it's trivial to fix by adding the right javac parameter. Much easier to fix than to edit the source code to duplicate every parameter name for no valid reason.

[glassfishrobot]

@ggam Commented @FroMage I think is also important to remark that those annotations can also be used on class fields and I think setters, where it will always work. Also, any runtime exception could actually be a deployment time error, so the inconvenience would be minimum.

[FroMage]

Is there any chance we can reopen this issue for consideration? We have added an equivalent annotation in RESTEasy that does just that and it's much better for user code.

[chkal]

Just to make sure I understand correctly. Java 8 supports preserving method parameter names in the byte code, is that correct? But it is not enabled by default?

[chkal]

For the maven-compile-plugin it is available as an opt-in. See the documentation for <parameter>.

[FroMage]

Yes, and the frameworks can detect that it has not been enabled and warn if required.

[mkarg]

As it seems a solution might be possible I have reopened this issue.

[hantsy]

Spring also supports this feature by compiler parameters enablement.

[mkarg]

Spring also supports this feature by compiler parameters enablement.

Maybe you like to file a PR against branch release-5.0?