XML for module descriptor

[Jaroslav Tulach]

Hello David, Neil,
if I was supposed to marry the benefits of XML (tooling, extensibility, 
encoding) with ability to parse the info, I would claim that module-info.xml 
is a source format which gets compiled by javac into module-info.class. 
module-info.class would contain all the information needed by Jigsaw runtime 
(so there is no XML processing in the core) and somehow stored the rest of the 
information in the XML for other systems to process later (most trivially as 
whole XML kept in an attribute of module-info.class, but possibly in better 
way).

If there is a utility to read MANIFEST.MF in core, it is not bad idea to reuse 
it. Properties like format (which manifests are using) is almost as extensible 
as XML, although validation tools are hard to find[1].

Anyway I seem to like the approach of having two extensible formats. One which 
is easily editable and audit-able (in spite of requiring sophisticated tools 
with high memory and CPU consumption) and one that is easy to process with 
minimal CPU cycles (generated during compilation). 
-jt

[1] This would probably not happen in XML: 
http://wiki.apidesign.org/wiki/PropertyFiles


>## 26. 3. 2012 22:27:18 ##<
> 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.