Exporting - the wrong default?
pbenedict at apache.org
Mon Aug 1 15:38:53 UTC 2016
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
On Mon, Aug 1, 2016 at 9:04 AM, David M. Lloyd <david.lloyd at redhat.com>
> 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
>> 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
> - DML
More information about the jigsaw-dev