Exporting - the wrong default?

[David M. Lloyd]

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