I'm generally pretty skeptical that the entire greater Java ecosystem
will converge in one single, mutually cohesive module environment, at
least on the Java side of the fence (the Ceylon story is probably
different since its ecosystem is cultivated by a much more unified will,
at least at this moment). The evidence suggests that we're a long way
away from such a place, if it is even possible at this point with all
the legacy code in existence. This is why I originally pushed not for a
new, ivory-tower module system design, but for a series of enhancements
to the existing modularity capabilities in the JDK to enable the
additional use cases that are stipulated in the requirements, which
would have resulted not only in a *dramatically* smaller patch to the
JDK but also a much simpler forwards- and backwards-compatibility story.
But, whatever; at this stage I'd settle for whatever small
improvements I can squeeze out of this stone.
As for manipulating module descriptors, I'm certain all kinds of tools
will turn up. But these kinds tools would exist to work around the
conceptual problems of Jigsaw; why not just solve the problems instead?
It's pretty common in our case for us and for users to want to
manipulate external descriptors for various purposes, but we're an
application environment, essentially; a curated distribution of modules
which is maintained and tested over time. I think that there is a limit
to how complex a Java application can get before it will become
impractical to develop further without such an environment, either
internally or externally maintained. Many users can build on such an
environment as-is, but I think there will continue to be a sizable
contingent that will need to manipulate these things, and I don't see
why it has to be made more difficult than it already is.
At the very least, with the JSR issues raised (including making some of
the overarching module rules be Layer concerns, and allowing the Layer
the ability to lazy-load modules), I am hoping that we can work around
some of the limitations and continue doing what we're doing with
external descriptors while still being able to present some of the
useful additional capabilities of JDK modules to users (which, for us at
this point, are amounting more or less to having module names and
versions appear in stack traces, and being able to upgrade bits of the
JDK somewhat more easily). But it's unfortunate (and a little bizarre)
that this is the place we're in, when the requirements seemed so
straightforward.
On 05/11/2016 09:55 AM, Stephane Epardaud wrote:
I expect such a tool to generate module-info.class to materialise. I
personally use ClassWriter from the JDK tools for that. Anyone with a
JDK has that module and can write that tool trivially.
The JBoss Modules use-case (and the Ceylon distrib one) is rather
uncommon, though, IMO. Most people deal with modules as Maven modules
and they can't really rewrite the descriptors as in most cases they're
not in the jar and Maven will only use descriptors from the repos and
not in any flat folder where you have Maven jars (I think). In
Maven-land you deal with this via external (to the modules being
overridden) overrides, which Java Modules don't support ATM.
OSGi is already a pain to override because you have to extract the
manifest, edit it and put it back. Here a tool would help. Overriding
Ceylon modules is done via external overrides too, otherwise you'd have
to extract the manifest (which is also a .class), edit it and put it
back, for which we'd have generated tooling if there was ever demand for
that (but there hasn't been yet).
All that to say, in general after-packaging editing of module
descriptors is already either rare or hard. I don't think
module-info.class changes that much.
On 11/05/16 16:44, David M. Lloyd wrote:
On 05/11/2016 09:21 AM, Stephane Epardaud wrote:
I don't understand the problem with the module-info.java class. We also
repackage jars to add module descriptors (for OSGi, Maven and JBoss
Modules) and for Jigsaw we generate the `module-info.class` file when we
need to repackage them. Between this binary format and XML or
MANIFEST.MF, I don't see why it makes a big difference?
I wouldn't recompile the module, though, just as I don't recompile them
when we change the other manifests.
If you have a .class file, you have to generate it with something. I
think Alan is arguing that it should be done with javac, but we'd
likely end up using something else. In our case, just editing an XML
file and doing "git commit" is easier than running a tool to read and
update a binary descriptor inside an artifact though, particularly as
we don't package the actual artifacts. Thus we'd have to package a
textual descriptor of some sort, to which we'd then have to apply a
tool in order to update our final packaged artifacts, making it that
much more difficult to use artifacts that already exist (e.g. from
Maven).
In addition it is common for our users to examine or modify module
descriptors; having them be external is very useful for this purpose.
We also allow features like specification of properties for modules
which can be read, specification of module permission sets, and
filtering of artifact resources and module dependencies in various ways.
--
- DML
