----- Mail original ----- > De: "Stephen Colebourne" <scolebou...@joda.org> > À: "jigsaw-dev" <jigsaw-dev@openjdk.java.net> > Envoyé: Mardi 26 Juillet 2016 18:42:47 > Objet: Re: Exporting - the wrong default?
> 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) it's better if module-info.java and module-info.class are aligned > > 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). I've sympathy with that idea but i think it's because non-exported package by default means that types are not available at runtime. non-exported package should have their types visible by reflection at runtime unless the package is declared restricted. > > 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 you rename a package using ASM 6 (currently in alpha version), it will also rename the package name in the module-info.class. i fail to see the issue here, obviously apart from the fact that the tools need to be updated. > > 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. Rémi > > > 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
