XML for module descriptor

[Jaroslav Tulach]

>## 23. 3. 2012 08:07:16 ##<
> 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

I cannot speak for the Jigsaw team, but (while my organization also needs 
concurrently extensible module-info[1]) there may be a reason why not use XML 
instead of module-info.class[2].

It is my understanding that one goal of Jigsaw is to make core Java really 
small and allow it to execute on very limited devices. The core needs to 
understand module-info. Right now the core contains ~3000 classes. If you 
bring full XML parsing infrastructure in, then you increase the size by ~4000 
new classes (that was my observation when I worked on splitting JDK last 
time[3]).

You could argue, that XML need not be fully featured one, but some simplified 
variant. Something that can be parsed by 30KB parser and not bloated Xerces. 
But that is not much different from using binary module-info.class[4].

-jt

[1] http://wiki.netbeans.org/Jigsaw
[2] please note that I am not talking about module-info.java
[3] http://wiki.apidesign.org/wiki/Modular_Java_SE
[4] If module-info.class format was made truly extensible


> 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.

PS: Linux distributions always recompile upstream projects from sources, so 
they would be patching module-info.java - which would be simple textual diff.