XML for module descriptor
jaroslav.tulach at oracle.com
Mon Mar 26 13:51:22 PDT 2012
>## 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) there may be a reason why not use XML
instead of module-info.class.
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
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.
 please note that I am not talking about module-info.java
 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.
More information about the jigsaw-dev