Code review request (original) (raw)

Remi Forax forax at univ-mlv.fr
Tue Feb 26 13:40:37 UTC 2013

On 02/26/2013 02:11 PM, Paul Sandoz wrote:

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.

amen :)

Paul.

Rémi

More information about the core-libs-dev mailing list