module-info.java just causes problems

[David M. Lloyd]

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