XML for module descriptor (was Re: What is a language construct? (was Re: Comment on state of Project Jigsaw))

[Eric Johnson]

Hi David,

On 3/23/12 12:42 PM, David Bosschaert wrote:
> Just FYI I started modifying OpenJDK/Jigsaw in the context of the
> Penrose project to see if something like module-info.xml instead of
> module-info.class/.java would work. From the prototype that I made it
> seems to make a lot of sense. See here:
> http://mail.openjdk.java.net/pipermail/penrose-dev/2012-March/000023.html
>
> Best regards,
>
> David
Thanks for exploring this question. I'm excited to see that someone has 
taken up this work.

For the trivial case you note, the XML, of course, looks mildly more 
complicated, if only because the namespace declarations add to the 
verbosity (and I note that you left off the <?xml version="1.0" ?> 
prologue). However, I think that is vastly outweighed by the significant 
increase in the number of tools that can immediately process the data - 
for example, I can write a script that extracts the module file from 
every module in a set, and then walks through the XML to generate an 
HTML report of the same. All without having to know a thing about Java 
class file formats.

For another example, I can edit the XML in Eclipse today, and apply the 
schema so that I know I am doing it correctly. And I can do that without 
having to wait for the Eclipse Java toolkit to improve to handle the new 
module-info.java syntax. Of course, as noted in previous discussion, 
this won't encompass the runtime validity of the data (can the required 
modules be resolved?), but it will ease the development of the contents 
of said files. As I know developers who still insist on using Emacs and 
its derivatives, I think this is enormously useful.

For yet another scenario, when a Linux distribution needs to patch 
upstream module metadata for whatever reason (for example, changing a 
choice of security module dependency), it will be far easier to alter an 
XML file (treated as text, most likely), than to patch a 
module-info.java file, then recompiling said file.

And, as you note, extending the data you can put into the module file is 
trivial, in the sense that you can simply add new namespace declarations.

In other words, I see many reasons for a hearty +1 to your prototype!

-Eric.