Public defender methods and static inner classes in interfaces?

[Reinier Zwitserloot]

A fix for this would be rather drastic; no access modifier usually means
"package", but it can't here, because in versions of javac up to and
including 1.6, no access modifier meant "public". "package" as an access
modifier could be introduced, but, that's what I meant with "a bit of a
drastic change". "protected" would also be wrong, it would imply that
implementers of the interface get to see and call it. Seeing it from just
about anywhere is what we're trying to avoid.

A lot still depends on whether or not the implementation of an extension
method is legally allowed to be invisible and/or inaccessible from the point
of view of the caller to an extension method. I'm guessing no, which makes
the point behind the request to allow private inner classes moot.

If the only use of private inner classes in interfaces is to serve as
convenient container for extension methods, testing isn't hampered much; you
can use the extension method access point to call it. The only thing you
couldn't directly call from test code is helper methods, at least not
without resorting to reflection.

 --Reinier Zwitserloot



On Wed, Sep 8, 2010 at 2:59 PM, Jim Mayer <jim at pentastich.org> wrote:

> 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
>>
>> ...
>>
>