Public defender methods and static inner classes in interfaces?

[Jim Mayer]

I understand, but access to helper methods is exactly what's wanted when
unit testing.

There's a natural tension between unit testing and information hiding.  I've
seen a lot of folks move in the direction of using interfaces for
information hiding and putting the implementation (with package level access
to internals) into a separate file.  Of course, those classes are
technically still accessible, but Java doesn't seem to be designed for that
level of information hiding.  At least with the separate file/package
approach only the public methods of the "default" implementation need to be
visible.  That seems relatively benign, and no language change is required.

The original Java design choice of not providing a keyword for package level
access was, in my opinion, unfortunate, and this problem is an example of
why.  "Fixing" that has got to be way out of scope, though :-(

<irony>
We could  improve the language even more by adding "friend" declarations.
:-)
</irony>

-- Jim


On Wed, Sep 8, 2010 at 10:18 AM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

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