XML for module descriptor

[David Bosschaert]

Hi Jaroslav,

On 26 March 2012 16:51, Jaroslav Tulach <jaroslav.tulach at oracle.com> 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]).

You certainly don't need a full blown XML parser. I think a restricted
one is fine. In my prototype I modified the (ASL2-licensed) Apache
Piccolo project to get things to work. I didn't optimize at all.
Piccolo.jar is about 160KB and around 50 classes in its original form
but that includes all the SAX and JAXP interfaces that go with it.

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

Right, I have seen XML parsers implemented in jars < 15Kb so if we
decide to go this route a dedicated parser could be implemented in
such a small footprint.
I think it would be *very* different from parsing the module-info.class because
* XML can be authored by a myriad of existing tools out there
* XML can be read by humans
* XML provides a well-defined extensibility model (using custom name-spaces)
* XML can be parsed easily by other module systems (as they most
likely have an XML parser at their disposal)
* XML can be parsed easily by other tools that wish to operate on
module information

On the other hand, I'm not married on XML - another textual format
might also do the job. I'm open to ideas here.

Cheers,

David