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
