Exporting - the wrong default?

[Alan Bateman]

On 26/07/2016 17:42, Stephen Colebourne wrote:

> :
>
> 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.
One thing that I like with the current design is that there is one 
authoritative source file that describes the module. It's nice to edit 
one source file when you want to examine or change the set of packages 
in the API, the dependences, and of course the services used and 
provided. Also declaring the set of the API packages that are exported 
shouldn't be a big surprise. There are many module systems built on top 
of the platform where you will see similar.

I do see your point about it being a potential chore when starting out, 
esp. when a new module is in development and the API packages are in 
flux. However I would expect that in time that the IDEs, the refactoring 
support in particular, will help. Also once the API has settled a bit, 
and other modules start depending on your module, then the number of 
changes to the exports list will reduce.

-Alan