Expose Record accessors / canonical constructor?

Brian Goetz brian.goetz at oracle.com
Fri Jun 19 15:18:27 UTC 2020


> 
> Recently I dabbed into a few binding APIs, to see how they can work with records, and to better understand their challenges.

Thanks for this!

> One particular thing I found was that you usually have to open the package that contains the record to the binding library.
> This is a task where the IDE won't help with. To illustrate, I basically want to write the following:
> 
>     record Person(String first, String last) {}
>     List<Person> persons = db.query("SELECT first, last FROM persons", Person::new);
> 
> The problem with the lambda is: what is it's target?

Right, even if Person only has a single constructor (so no overload selection problem), we have to assign a type to Person::new, and there isn’t necessarily a good one.  I would expect libraries to do as you suggest, pass Person.class, which is not unreasonable here.  You’re saying “I want to do query Q and map it to a List<P>, and a type token is a reasonable way to do that (given the language we have.)

> As Person is a local record, a framework can't directly call the canonical constructor or the accessors, instead it has to call setAccessible.

Good catch!   This is the sort of thing that falls through the cracks as we expand the use of local members. (This problem has existed for years, apparently, but no one noticed until today, when we gave them a better reason to use local classes.)  

> Is my assumption that frameworks should be able to construct and deconstruct arbitrary records correct?

IMO what you’re doing is what we intended records to be used for.  

Let’s think on this …




More information about the amber-dev mailing list