[External] : Limitation of Interfaces

[Fede Peralta]

Hi Nir,

I think it would be useful to know what real problem you're trying to
solve. I'm almost sure there's a way to achieve what you want with what the
language offers now. I remember that I once needed to implement an
interface with callback methods, but I didn't want these callback methods
to be public. The solution was already available in some issue of the
javaspecialists newsletter and was something like this (simplified):

public interface A {
    void method();
}

public class AImpl {

    private SomeoneThatNeedsMyCallback handler;
    private String someField; // etc

    private final A inner = new A() {
        public void method() {
            // real implementation goes here
            // modifies AImpl.this.someField and other state
            // performs side-effect actions, etc
        }
    }

    // Non-public constructor
    AImpl() {
        this.handler = new SomeoneThatNeedsMyCallback(inner);
    }

   // Non-public, can even be private
    void method() {
        // delegates to inner.method()
        inner.method();
    }
}

You might also need that AImpl actually implements A. In this case, make it
so, but also make the public method method() a no-op, i.e. without
implementation and, if needed, add a new non-public method to AImpl, i.e.
safeMethod() that delegates to inner.method()

The code becomes more compact if you use lambdas and/or method references.

Disclaimer: I'm not from Oracle, just a guy that loves this list :)
Regards,
Fede

El mar, 18 ene 2022 a las 17:14, Brian Goetz (<brian.goetz at oracle.com>)
escribió:
>
> Don't forget that interface fields are always static, so this may not
> help as much as you think.
>
> On 1/18/2022 3:03 PM, Nir Lisker wrote:
> > (Sorry about forgetting the subject line, I added it now)
> >
> > Actually protected methods wouldn't save me either since they are part
> > of the public API. I either need "protected but not public API" or
> > package-private, which is less suitable but probably easier. I think
> > that in this case private fields in interfaces will be more ideal.
> > Good to know that this is something that can be changed in the future,
> > even if it's not on the drawing table yet.
> >
> > On Tue, Jan 18, 2022 at 9:52 PM Brian Goetz <brian.goetz at oracle.com>
> > wrote:
> >
> >     The full range of accessibilities for interface methods was
> >     discussed at some length during the design process.  Interfaces
> >     were extended to support private methods, which leaves questions
> >     hanging over whether protected and package-private methods could
> >     also be supported in interfaces.  (Also, it's limiting that
> >     private fields/classes are not permitted in interfaces, which
> >     would be very useful, and this was mostly an oversight, which will
> >     probably be fixed eventually.) What you want -- protected methods
> >     in interfaces -- are more complicated than it might first appear,
> >     because the semantics of "protected" are also more complicated
> >     than they first appear.  It is probably possible but would surely
> >     be a lot of incremental complexity for not as much incremental
> >     expressivity.
> >
> >
> >
> >
> >
> >     On 1/18/2022 2:25 PM, Nir Lisker wrote:
> >>     I'm not advocating for multiple inheritance or new visibility
modifiers
> >>     (though here there is a broader issue where library designers want
a
> >>     "protected but not public API" kind of visibilit), but I would
like to not
> >>     need to copy-paste the same code everywhere, whatever the solution
might
> >>     be. Is there a solution?
> >
> >