<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">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". <br>
<br>
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.) <br>
<br>
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. <br>
<br>
<br>
</font><br>
<br>
<div class="moz-cite-prefix">On 12/8/2024 8:52 PM, Peter Eastham
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAN+txM-RvB1pAgdYT2S3pC_=Fyrp7FY09vEhW2T4hyE0vywqYw@mail.gmail.com">
<div dir="ltr">Hi Amber team,<br>
<br>
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.<br>
<br>
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)<br>
CriteriaQuery q = cb.createQuery(Customer.class);
<br>
Root customer = q.from(Customer.class);<br>
Join order = customer.join(Customer_.orders, JoinType.LEFT);<br>
q.where(cb.equal(customer.get(Customer_.status),
1)).select(customer); <br>
<br>
If there was greater access to the Method Reference more
implicit information could be passed, reducing the noise,<br>
CriteriaQuery q = CriteriaQuery.createQuery(Customer::new)<br>
.leftJoin(Customer::orders)<br>
.where(Object::equals, Customer::status, 1);<br>
var result = q.select();<br>
<br>
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.<br>
<br>
Thanks,<br>
-Peter</div>
</blockquote>
<br>
</body>
</html>