Code review request

Paul Sandoz paul.sandoz at oracle.com
Tue Feb 26 05:11:50 PST 2013


On Feb 25, 2013, at 10:45 PM, David Holmes <david.holmes at oracle.com> wrote:

> On 26/02/2013 3:31 AM, Paul Sandoz wrote:
>> Hi Remi,
>> 
>> Thanks for the feedback i have addressed some of this, mostly related to
>> inner classes, in following change set to the lambda repo:
>> 
>> http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e50294c68ea
> 
> I see a lot of private things that are now package-access.

I presume you mean on constructors of private inner classes?


> Is that because they are now being used within the package?
> 

No, it is to avoid the creation of a synthetic package private constructor called by enclosing class to construct the inner class.


> The access modifiers document intended usage even if there is limited accessibility to the class defining the member. The idea that a class restricted to package-access should have member access modifiers restricted to package-only or else private, is just plain wrong in my view. Each type should have a public, protected and private API. The exposure of the type within a package is a separate matter. Package-access then becomes a limited-sharing mechanism.
> 

For private inner classes i took the view that protected on fields offered little value, but paused for top level classes.

There are not many use-cases in the JDK at least for the packages i browsed. The class java.util.concurrent.atomic.Striped64 does not bother with protected.

I am leaning towards the opinion that protected is just noise in these cases since the compiler offers no protection.

Paul.


More information about the lambda-libs-spec-observers mailing list