Exporting - the wrong default?

[Stephen Colebourne]

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.topic at 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