Improving Method Reference Ergonomics

[Brian Goetz]

By "greater access", I think you mean "if they could be reflected on as 
a function, not just a thunk of behavior", yes?  Then 
`createQuery(Customer::new)` would be able to reflect over the 
constructor reference and see "oh, it's a constructor for Customer".

We've given a good deal of thought to this problem, but it's messy for a 
number of reasons, including erasure and limitations on the static type 
system.  Does createQuery mean to limit to method references, rather 
than all lambdas?  If so, then Supplier<T> is not a sharp enough type, 
and users could pass a Supplier that ends up causing a dynamic failure.  
If not, then it sounds like what you want is to reflect over the 
concrete shape of the supplier, which runs into erasure problems (among 
others -- what if you intended a Supplier<Foo>, but the lambda you 
passed instantiates a Supplier<SubtypeOfFoo> where the subtype is 
inaccessible to the framework.)

So while it is possible to associate more metadata with method 
references than we currently do, and we've considered it, most of the 
obvious paths run into obvious roadblocks just a bit farther down the road.




On 12/8/2024 8:52 PM, Peter Eastham wrote:
> Hi Amber team,
>
> Earlier this week I was playing around with fluent API design, and I 
> believe Java could benefit from some improvements to the usage of 
> Method References, I'll keep this short with the following example.
>
> Lets take the following JPA Criteria from section 6.3.3 of the 
> Specification, (Only for an example of what an API could begin doing, 
> not should do)
> CriteriaQuery q = cb.createQuery(Customer.class);
> Root customer = q.from(Customer.class);
> Join order = customer.join(Customer_.orders, JoinType.LEFT);
> q.where(cb.equal(customer.get(Customer_.status), 1)).select(customer);
>
> If there was greater access to the Method Reference more implicit 
> information could be passed, reducing the noise,
> CriteriaQuery q = CriteriaQuery.createQuery(Customer::new)
>   .leftJoin(Customer::orders)
>   .where(Object::equals, Customer::status, 1);
> var result = q.select();
>
> Regarding what should be available, the resolved Class and Method name 
> at least, anything else I'd leave up to the feasibility of the change.
>
> Thanks,
> -Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241209/3f3409b7/attachment.htm>