Code review request
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:
> 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 lambda-libs-spec-experts