The purpose of this change is meant to be to enhance Java. While security may be part of the issue being tackled, it has never been claimed as the main one. This proposal does not make it much of an issue either, as the runtime would likely still have a list of exported packages - it would be the declaration format (module-info.java) that would change. (javac has a closed set of packages when compiling a module, so outputting exports in the binary but using restricts in module-info works just fine)
I think a key problem is that those working on the JDK have a warped sense of what a typical Java project is like. In many projects packages change names frequently during development, everything is open and locking stuff down is the last thing on peoples minds. While this of course leads to slightly less secure software, it does achieve *business value*. The current default to force developers to list all exports is simply going to slow developers down for no perceived benefit. (In fact with Java EE and OSGi excluded from modules, they really don't seem all that useful anyway). The "robust in the face of change" argument is dubious too. If you want package exports to be robust in the face of change, the export/restruction criteria should be in packag-info.java, not module-info.java, where it would automatically be handled by all existing tooling for renaming packages. If the default does not change, then I assume the tools will effectively work around it. ie. that Maven will have an option to export all packages not explicitly hidden. Anything else would be far too annoying for development. Stephen PS, I would accept a design where developers could choose to use exports or restricts (but not both) in module-info.java. On 26 July 2016 at 11:48, dalibor topic <dalibor.to...@oracle.com> wrote: > 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
