Consider having @BeanParam support Record Classes

[fwgreen]

Records look like a good fit for @BeanParam support:

record PersonForm(@FormParam("name") String name, @FormParam("age") int age) {}
//...

@POST
@Produces(MediaType.TEXT_HTML)
public Response post(@BeanParam PersonForm form) {
    //...
}

[mkarg]

Unfortunately records are just in preview even in JDK 15.

[fwgreen]

Because of the faster release cadence, I'm hoping for a conversation on what's required to start now, as the plan (as of July) is to finalize Records in JDK 16 (due in March 2021).

[arjantijms]

Although we're set to solving the issues, and taking advantage of Java SE is very important, the Jakarta Rest spec is bound by the version of Java that the TCK describes (both standalone as platform).

That should therefor allow certification on JDK 16. I'm greatly in favour to make this possible/allow this, but as of yet the TCKs are very, very tightly tied to JDK 8.

[jansupol]

I do not think that TCK's flexibility should decide what the Spec shall support. It is up to the Spec to define what JDK version it supports. There is a bunch of requirements in many specs that are untestable by the TCKs at the moment.

[pearceeverydaylabs]

any possibility of reconsidering this now that java 16 records have arrived (and given that there seems to be differing opinions about whether current TCK should block this)?

[andymc12]

IIUC, a record is really just an immutable class. If we supported immutable classes (which would work in all Java versions), we could implicitly support records. So we could modify the spec to indicate that implementations must support constructor injection of *Params for BeanParam classes. Then we would be able to support something like this (for all Java versions):

@POST
@Produces(MediaType.TEXT_HTML)
public Response post(@BeanParam PersonForm form) {
    //...
}

//...

class PersonForm {
    private final String name;
    private final int age;
    PersonForm(@FormParam("name") String name, @FormParam("age") int age) {
        this.name = name;
        this.age = age;
    }
    //....
}

In Java 16, a record like the following would effectively create that class anyway:

record PersonForm(@FormParam("name") String name, @FormParam("age") int age) {}

so we would have support for Java 16.

I haven't tested it yet, but I wouldn't be surprised if some JAX-RS implementations already support constructor injection of *Params...

[mkarg]

Andy's approach sounds feasable to me.

[zanmagerl]

Is there any new progress on that?
Records are now available in Java 17 (which is LTS) and it makes sense to use records for @BeanParam. For example, given query parameters in REST call are most commonly immutable and records are intended for such use cases.

[spericas]

Jakarta REST 4.0 will likely be supporting JDK 17 or later (in alignment with Jakarta 11). We can add a note about records in the spec.

[jansupol]

I would be concerned about this. Jakarta REST 4.0 should use CDI. CDI would instantiate the records, but the injection into records does not work with CDI, since the records are immutable.

[ksdev-pl]

Hello. Are there any plans related to it, as it looks like Jakarta REST 4.0 doesn't support records?

[mkarg]

@ksdev-pl Thank you for reactivating this discussion!

@jansupol IMHO CDI supports constructor injection, so what actual issue do you see?

[douglas444]

@jansupol @mkarg @spericas Guys, we need record support. Records are much more suitable for data transfer objects, as their main purpose (data transfer) does not require mutability. Java records are just perfect for that.

Beyond that, it would be nice to have the form parameter derived from the attribute name in case the annotation is omitted. This means that, for this method:

@POST
@Produces(MediaType.TEXT_HTML)
public Response post(@BeanParam PersonForm form) {
    //...
}

This
record PersonForm(@FormParam("name") String name, @FormParam("age") int age) {}

Would have the same effect as this:
record PersonForm(String name, int age) {}

You shouldn't need to inform the form parameter annotation if the value is the same as the attribute name.
This would also allow the record/class to be decoupled from framework details.

Due to the lack of record support and the need to annotate attributes with the FormParam annotation, I have seen a couple of server-side systems avoid the Jakarta rest API or just use fetch in their frontend instead of forms so that they can use plain decoupled records (with RestEasy).

How can we make record support happen? What about the need for the FormParam annotation? Can I help somehow?

[mkarg]

How can we make record support happen? What about the need for the FormParam annotation? Can I help somehow?

As soon as we have an implementation as a PoC we can discuss the actual wording needed in the spec and JavaDocs. So if anybody is willing to supply a PR for a PoC in one of the CIs, this would be something you could definitively help with. 🙂

[FroMage]

Quarkus REST already supports record parameter containers: https://quarkus.io/guides/rest#grouping-parameters-in-a-custom-class

Note that in Quarkus REST we have made the @BeanParam annotation optional (it is implied when an endpoint method parameter has fields that are @*Param or implicit parameter containers).

As a result, we can't make @FormParam implicit on records, because we wouldn't be able to auto-detect parameter containers. Besides, @FormParam is also not an implied default on method endpoint parameters, so it would be irregular. Lastly, my personal opinion has always been that the proper place for @BeanParam (if it ever was useful, since it can trivially be inferred) was on the parameter container class itself, and not on its use-sites.

Also note that the most annoying part of having to specify @FormParam is the non-optional value where you repeat the parameter name in 99% of the cases. This should definitely be made optional a decade after Java supported recording parameter names (despite not making it mandatory, unfortunately). To alleviate that, in Quarkus REST we have copies of the @*Param annotations under the names @Rest* to allow for the value to be optional and not repeat the parameter name. With this, specifying @FormParam becomes fairly acceptable and minimal and doesn't really need to be implied.