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
