XML for module descriptor

[Neil Bartlett]

On Monday, 26 March 2012 at 21:51, Jaroslav Tulach wrote:

> > ## 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]).
>  
>  

I agree that bloating the core with an XML parser would be undesirable, but at the same time support David's desire for an extensible, textual format. If there were a textual format with a parser already supported in the core then perhaps this could be used. For example the MANIFEST.MF parsing in java.util.jar is currently part of core, I believe.

Regards,
Neil
> 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.
>  
>