On Wed, Oct 6, 2021 at 2:08 PM Brian Goetz wrote:
> One more thing we could do is reach out to the most popular libraries that
> do this and give them a heads up that they need to tolerate the field not
> being there.
>
Good idea, I filed bugs against several libraries that are reflecting on
fie
You can't actually do this: that signature is a promise to return an
instance of *any* class implementing those interfaces, not *some* class
implementing them. If you try to implement your getCloseableFoo method,
you'll find that no implementation compiles. For example:
final class tmp {
static
I'm sorry that I appeared to be suggesting that there were no other reasons
to suppress it. I was actually giving just one example. Nevertheless, the
check has done more good than "harm" (in the form of these small
suppression costs).
On Thu, Oct 7, 2021 at 2:08 PM Remi Forax wrote:
>
>
> -
> From: "Kevin Bourrillion"
> To: "Maurizio Cimadamore"
> Cc: "Brian Goetz" , "amber-spec-experts"
>
> Sent: Jeudi 7 Octobre 2021 22:37:58
> Subject: Re: Minor improvement to anonymous classes
> On Thu, Oct 7, 2021 at 7:37 AM Maurizio Cimadamore < [
> mailto:maurizio.cimadam...@oracle.com | mau
On Thu, Oct 7, 2021 at 7:37 AM Maurizio Cimadamore <
maurizio.cimadam...@oracle.com> wrote:
> X getCloseableFoo();
>
> Which kind of works, but it's quite an horrible hack (you introduce a type
> parameter you don't need - which means compiler will try to infer types,
> etc.)
>
(Incidentally, we
Your proposal is for anon classes, which I think works well.
One related case I found quite often is the desire to combine types e.g.
in a return type:
Foo & AutoCloseable getCloseableFoo();
This veers into declaration-land, visible to javadoc and all. So it
probably doesn't have a good bene
