On 26.07.2016 12:30, Stephen Colebourne wrote:
This does not appear to change the underlying model of modules (reliable configuration and strong encapsulation), but would make it much more practical to use.
It wouldn't be as robust in face of change, as it would require consciously tracking new packages being added to a module and explicitly marking them as internal, or living with design mistakes (or other problems) because someone forgot to immediately restrict access to something that was supposed to be internal.
For a much longer explanation, see "Fail-safe defaults" in https://buildsecurityin.us-cert.gov/articles/knowledge/principles/failing-securely
cheers, dalibor topic -- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
