XML for module descriptor

[David Bosschaert]

On 29 March 2012 13:05, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 28/03/2012 19:52, Rémi Forax wrote:
>>
>> :
>> As I already said, the best is to develop a small parser
>> that is able to parse a module-info.class and provide
>> XML events or properties.
>
> FWIW, ModuleSystem already defines a parseModuleInfo method for parsing
> module-info.class files.

This is yet another reason why I think it's weird to use .class files.
Normally .class files are read by the VM, but in this case a special
java class is written to read the .class file. So it's used as just a
data file, which again underlines the point that using .class files is
not the right thing to do here.

> On XML then the current prototype base module does not include JAXP or any
> XML support.

Right, so if we go with XML we'd have to embed a tiny parser that is
just good enough to read the XML definition, which isn't hard to do. I
have currently an implementation that (when jarred-up) is about 85kb,
but as mentioned before it should be possible to optimize that into
something smaller.

I've been thinking about alternative representations. Although I think
that using MANIFEST.MF is better than using module-info.class, there
are still some issues with it: the fixed line-length and other
esoteric formatting rules and the fact that when using it one
generally needs a second-level parser to parse the value of a header,
I mean the JRE Manifest parser could return the following from an OSGi
Import-Package header,
  org.osgi.service.log;version="[1.3,2)",org.osgi.util.tracker;version="[1.4,2)"
but that will then need to be fed to another parser to be processed.
It would be nice that whatever format we come up with can use a single
parser to do all the parsing for us :)

So I've been thinking a little more about alternative representations.
Given the following XML (which I have working on my penrose clone)
  <module name="org.astro" version="1.2"
xmlns="http://www.jcp.org/xmlns/modules/v1.0">
    <exports name="org.astro.somepackage"/>
  </module>

This could also be represented as JSON like this:
  module {
    "name" : "org.astro",
    "version" : "1.2",
    "exports" : [
      { "name" : "org.astro.somepackage"}
     ]
  }
I don't think the core contains a JSON parser, but again it should be
possible to write a really small one (possibly by leveraging the
java.util.Scanner class). Using JSON one can then add extensibility by
introducing the idea of namespaces. I don't think this is standard
JSON at this point in time, but I have seen people do it in the
following way (e.g. to add OSGi versioning to the package export):
module {
  "name" : "org.astro",
  "version" : "1.2",
  "exports" : [
    { "name" : "org.astro.somepackage", "org.osgi.version" : "1.0" }
   ]
}

I'd be happy to investigate the actual realization of this through
JSON if people think that's better than XML and MANIFEST.MF...

Cheers,

David