On 03/17/2017 03:50 AM, Stephen Colebourne wrote:
On 16 March 2017 at 16:21, David M. Lloyd <david.ll...@redhat.com> wrote:
3) Remove the concept of automodules entirely
Migration would be slower, but safer. Tooling might evolve to add
module-info dynamically as part of the build or runtime system, or by
editing all the jar files in Maven Central to have an auto-generated
module name.
Indeed, it would be relatively easy to introduce a tool that would assemble
an arbitrary set of JARs into a module graph, using a configuration
descriptor for only the most advanced cases (pruning the service list,
specifying reflection capabilities if they are more specific than "open
all"). Such a tool would be superior to automatic modules in many ways.
This approach has other important advantages: zero magic (particularly if a
tool can describe what it has done concisely), and choice of implementation.
Even as I was writing this, a colleague of mine sent me a message that he
has already independently created such a tool. The URL is:
https://github.com/moditect/moditect
Er, I can't think of a viable option 4.
4) Support a mode of operation where the descriptor is external to the
module content.
Containers are already going to be doing this anyway after all. This is
similar, in a way, to option 3 where tooling (or a person, if we can ever
break away from this idea of requiring bytecode for this purpose) would be
able to establish the modular environment without modifying the artifacts.
This is a model that we use today with success.
I think a solution to automodules cannot _require_ a container or a
tool. Option 3, "remove automodules", merely suggests that by removing
them containers or tools _may_ fill _some_ of the gap. But
tooling/containers can't fill the gap for the key part of automodules,
allowing the author of a module-info.java to depend on something that
has not been modularized. Which is why it is borderline as to whether
option 3 "solves" the specific problem in the original mail.
External descriptors allow an application to be stitched together from
jar files, modularized or not (where guessing module names is fine,
because it is the descriptor for an application, not a public
library). However, external descriptors don't solve the problem where
someone is writing a module-info.java file for a public library and
has to guess a module name for a dependency they don't own.
Note that I'm not disagreeing with the idea of an external descriptor,
just that I think it solves a different problem (and should exist
outside JPMS).
Something to remember is that naming is ultimately the responsibility of
the distributor of the final module assembly. The framework author(s)
can make a good guess about a name but (particularly where split API and
implementations or specifications are concerned) there's a very good
chance that any distributor of a nontrivial application is going to have
to perform substitutions anyway. Since this is likely to be a common
occurrence (at least with larger applications), it should be planned
for. If users are already expecting to use tooling to create their
assemblies, then automodules don't actually help because they just add
another axis of unpredictability to the assembly process.
I expect an assembly workflow to involve fetching artifacts with preset
versions, either transforming an existing descriptor or establishing a
new one (probably based at least on the combination of existing module
descriptors, Maven metadata, and (possibly) some small amount of user
configuration, which BTW will result in a far better "guess" than
automodules possibly could), and then finally bundling up the result in
some way (either jlink or via a more traditional mechanism).
This is why I think automodules should be dropped: I cannot envision a
real-world non-trivial development scenario where it could possibly be
helpful. And some auxiliary food for thought: today, it will fail on
any JAR set that includes SLF4J. Sorry SLF4J fans!
--
- DML
