Public defender methods and static inner classes in interfaces?

[Jim Mayer]

One problem with the suggestion below (that 'private' be allowed on classes
inside interfaces) is that it won't play nicely with unit testing frameworks
such as JUnit.  JUnit conventions rely fairly heavily on 'package'
protection, and a 'private' class inside an interface would be difficult to
test.

This may, or may not, matter in practice, but I hate to see us do anything
that makes unit testing harder.

My own preference, at this point, would be to keep implementation out of
interfaces as much as possible, provide implementations in a separate file,
and hope that the defender method feature isn't abused too much.  Perhaps a
convention like the following wouldn't be too ugly:

package some.package;

public interface Outer {

    public extension void method(Object parameter)
       default some.package.defaults.Outer.method;
}

Admittedly, "some.package.defaults.Outer.method" still has to be public, put
at least its purpose is pretty clear.

-- Jim

On Tue, Aug 24, 2010 at 6:25 AM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

> ...
>
> One suggestion I made was that 'private' now be allowed on classes inside
> interfaces, which would be backwards compatible (package private and
> protected remain illegal, and if no access level keyword is given, it'll be
> public, in order to remain backwards compatible. The JVM can already do
> this), though this idea does depend on whether or not an extension method
> has to be visible from the caller, which I'm guessing it has to be, in
> which
> case it can't be private. I can't recall any response to this idea,
> however.
>
>  --Reinier Zwitserloot
>
> ...
>