Exporting - the wrong default?

[Remi Forax]

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> À: "jigsaw-dev" <jigsaw-dev at 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.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