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