XML for module descriptor

[David Bosschaert]

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.

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.

Best regards,

David

On 26 March 2012 23:25, Jaroslav Tulach <jaroslav.tulach at oracle.com> wrote:
> Hello David, Neil,
> if I was supposed to marry the benefits of XML (tooling, extensibility,
> encoding) with ability to parse the info, I would claim that module-info.xml
> is a source format which gets compiled by javac into module-info.class.
> module-info.class would contain all the information needed by Jigsaw runtime
> (so there is no XML processing in the core) and somehow stored the rest of the
> information in the XML for other systems to process later (most trivially as
> whole XML kept in an attribute of module-info.class, but possibly in better
> way).
>
> If there is a utility to read MANIFEST.MF in core, it is not bad idea to reuse
> it. Properties like format (which manifests are using) is almost as extensible
> as XML, although validation tools are hard to find[1].
>
> Anyway I seem to like the approach of having two extensible formats. One which
> is easily editable and audit-able (in spite of requiring sophisticated tools
> with high memory and CPU consumption) and one that is easy to process with
> minimal CPU cycles (generated during compilation).
> -jt
>
> [1] This would probably not happen in XML:
> http://wiki.apidesign.org/wiki/PropertyFiles
>
>
>>## 26. 3. 2012 22:27:18 ##<
>> On Monday, 26 March 2012 at 21:51, Jaroslav Tulach 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]).
>>
>> I agree that bloating the core with an XML parser would be undesirable, but
>> at the same time support David's desire for an extensible, textual format.
>> If there were a textual format with a parser already supported in the core
>> then perhaps this could be used. For example the MANIFEST.MF parsing in
>> java.util.jar is currently part of core, I believe.
>>
>> Regards,
>> Neil
>>
>> > 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].
>> >
>> > -jt
>> >
>> > [1] http://wiki.netbeans.org/Jigsaw
>> > [2] please note that I am not talking about module-info.java
>> > [3] http://wiki.apidesign.org/wiki/Modular_Java_SE
>> > [4] If module-info.class format was made truly extensible
>> >
>> > > For yet another scenario, when a Linux distribution needs to patch
>> > > upstream module metadata for whatever reason (for example, changing a
>> > > choice of security module dependency), it will be far easier to alter
>> > > an XML file (treated as text, most likely), than to patch a
>> > > module-info.java file, then recompiling said file.
>> >
>> > PS: Linux distributions always recompile upstream projects from sources,
>> > so they would be patching module-info.java - which would be simple
>> > textual diff.