Exporting - the wrong default?

[David M. Lloyd]

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