module-info.java just causes problems

[Stephane Epardaud]

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.