XML for module descriptor
njbartlett at gmail.com
Mon Mar 26 19:27:18 PDT 2012
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) there may be a reason why not use XML
> instead of module-info.class.
> 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
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.
> 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.
>  http://wiki.netbeans.org/Jigsaw
>  please note that I am not talking about module-info.java
>  http://wiki.apidesign.org/wiki/Modular_Java_SE
>  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.
More information about the jigsaw-dev