requires public for automatic modules

[Alan Bateman]

On 22/04/2016 11:36, Paul Bakker wrote:
> Thanks for the answer Remi. I'm wondering if a (optional) build step is considered. During build the byte code analysis that jdeps does could be used to generate better metadata for automatic modules. This would be a compromise between using automatic modules without this metadata and actually adding a module-info to a JAR file (which isn't a great option for 3rd party libs).
>
> I've looked at several (small) code bases now, and using default modules keep resulting in a long list of transitive dependencies that I would prefer not to have in my module. Because of that a top down migration process doesn't result in proper modules when using automatic modules, and that would be a bad start when migrating to modules. The required trial and error work will frustrate users as well.
The intention when doing top-down isn't to do a bulk move, otherwise you 
end up with many automatic modules on the module path that nobody 
requires and then resorting to `-addmods ALL-MODULE-PATH`.

Instead, the intention is that you just move the components that 
"demonstrator" requires. This might mean using `jdeps` when migrating 
existing code, maybe using the -genmoduleinfo` option to generate an 
initial module-info.java to get you going.  The rest can be left on the 
class path until the owners of components that have moved are released 
as explicit modules.

That said, automatic modules and top-level migration is very much an 
area that needs real world experience and feedback. We definitely need 
more people trying it out and reporting back on whether they were 
successful or not.

-Alan