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
