XML for module descriptor

[Shi Jun Zhang]

On 4/13/2012 3:15 PM, David Bosschaert wrote:
> 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
>

+1

I think JSON is more readable than XML. And as MANIFEST.MF has 
limitations, it seems not to be a good choice either. YAML is another 
choice we can consider. The module info will be something like this:
module:
     name: org.astro
     version: 1.2
     exports:
         name: org.astro.somepackage
         org.osgi.version: 1.0

-- 
Regards,

Shi Jun Zhang