Code review request
forax at univ-mlv.fr
Tue Feb 26 05:40:37 PST 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:
>> 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