To echo David, there is a complaint by me in these archives how I still find it difficult to remember that "public" is no longer being public. I feel the same way today still. The word "public" means "for everyone" so it's always jarring to have it no longer mean what it should mean in normal English. Also, I find it less than appealing to do double-duty to make my classes public. I now have to remind myself to export my package but it's still something I forget. I find this step to be a nuisance. That's my real world feedback.
Cheers, Paul On Mon, Aug 1, 2016 at 9:04 AM, David M. Lloyd <david.ll...@redhat.com> wrote: > On 08/01/2016 05:40 AM, dalibor topic wrote: > >> >> >> On 29.07.2016 16:55, David M. Lloyd wrote: >> >>> On 07/29/2016 09:20 AM, dalibor topic wrote: >>> >>>> >>>> Is it safe to assume that all potentially headache inducing Guns and >>>> Bullets are always kept under lock in non-public classes? >>>> >>> >>> Of course, that's why we had non-public classes in the first place. >>> >> >> OK, let's assume that's correct for the deliberate headache instrument >> hiding decisions made by all Java developers for the sake of the argument. >> >> To balance that assumption out, please grant me an assumption as well: >> Let's assume for the sake of the argument that not all Java developers >> are experts all the time, and therefore some of them might sometimes >> produce classes that could be abused as headache inducing Slings and >> Stones. >> >> Is it safe to assume that all such involuntarily headache inducing >> Slings and Stones are also kept under lock in non-public classes? >> > > Of course not, no more than it is safe to assume that such will be kept > hidden in non-exported packages under the existing regime. At some point > the user has to make the decision to make something public or not public; > nothing can change that. But what we can do is to make it easy for users: > a public class is public, otherwise it is secret and has to be explicitly > shared. Contrast with the current system, where whole packages must have > their definition of "public" defined to mean either selectively shared or > fully public, which is less intuitive and more confusing. The more > confused the user is, the more likely they are to make a mistake about > security. With my proposal, if there are any doubts about a class, you > make it non-public (regardless of what package it is in), which is a very > simple criterion. In addition, you make the public/non-public choice on a > per-class basis, not a per-package basis, which is also useful as well as > intuitive. > > -- > - DML >
