XML for module descriptor

[Glyn Normington]

On 13 Apr 2012, at 10:47, Shi Jun Zhang wrote:

> 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
> 
> 

Any text solution beats a binary file.

JSON seems preferable to XML. I think YAML is not as suitable as JSON as it's harder to parse and perhaps more error-prone when hand-written.

Regards,
Glyn