On 07/28/2016 07:33 AM, dalibor topic wrote:
On 27.07.2016 17:37, Stephen Colebourne wrote:
While the JDK cannot afford to compromise on security, many real-world
systems can and do. Software is mostly a trade-off between security,
quality, features, delivery date, design, resources... etc. As such,
this discussion cannot and should not be shut down solely on the basis
of security.
For an entirely hypothetical straw man example, imagine the expert
authors of a third party component A making a deliberate security trade
off in one class. For the sake of brevity, let's call that class 'Gun'.
Let's also imagine a different set of expert authors of a different
third party component B making a different deliberate security trade off
in another class. Let's call that class 'Bullet'.
Assembling a software system H which, by simply using both component A
and component B, provides both a Gun and a Bullet, could lead to some
pretty bad headaches down the road.
In the "exported by default" world view, the assembler is responsible
for restricting all such headache inducing interactions between these
classes, originating in different components with different trade offs.
Let's hope for their sake they are really awesome experts at that sort
of thing, and especially good at handling the potentially exponential
complexities that can arise from adding new components with further
third party provided Guns and Bullets to their software system.
In the "failsafe by default" world view, they are responsible for
enabling "just" the non-headache inducing interactions between those
classes, of which there in most cases may very well be none.
That's (potentially) a substantial difference in effort necessary to
accurately make such trade offs, in particular over the maintenance life
cycle of a software system.
My proposal gives the best of both worlds: all public types of all
packages are always accessible, and only the secret/non-public types
need to be explicitly privately exported. You don't have to add new
public packages to the exported list, because exporting all by default
is a safe/sane default as well as being intuitive. On the other hand,
you have to go out of your way to provide additional access to new
private packages, which is also intuitive.
--
- DML
