XML for module descriptor

[Rémi Forax]

On 03/28/2012 08:09 PM, David Bosschaert wrote:
> Hi Jaroslav,
>
> I think combining module-info.class with an XML appendix really is the
> worst of both worlds, because it doesn't allow you to use XML tools to
> edit/view, as you end up with a combination binary/XML file. I would
> be much more in favour of staying within a textual format (XML,
> MANIFEST as Neil proposed, or something else) in the ultimate module
> where the actual JRE can cache a binary representation of this
> internally if it wishes to.
>
> WRT to he MANIFEST.MF, yes I think the core contains a parser for
> that, so it could be used. OSGi has leveraged the Manifest for about
> 14 years now without problems. I used XML in my prototype as it seems
> like a more versatile format than MANIFEST.MF and since we're
> designing something new here it might make sense to move to a more
> generally understood format. I don't think the implementation size of
> an XML parser which is only focused on parsing this file should be a
> big issue.

There are issues with manifest, the two main points for my students
are that they publish manifest that don't even parse
and the second one is that they keep in the manifest
generated information that are not true anymore.

>
> I have to say I don't like having 2 different official representations
> of the module info at all (sorry ;) as it carries all kinds of
> synchronization issues and possibly doubles the burden of supporting
> it. If you want a binary format I think the way to go is let the JRE
> implementation generate that under the covers and cache it to optimize
> speed etc.

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.

>
> Best regards,
>
> David

best regards,
Rémi