Code review request

Paul Sandoz paul.sandoz at
Tue Feb 26 13:11:50 UTC 2013

On Feb 25, 2013, at 10:45 PM, David Holmes <david.holmes at> 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:
> 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.


More information about the core-libs-dev mailing list