Source Code Generation

[Svante Schubert <sv...@gmail.com>]

Hello,

Just a quick update on my work on our source code generation.
The analysis of ODF RelaxNG schema via a GraphDB using Apache Tinkerpop is
still improving
<https://groups.google.com/forum/#!topic/gremlin-users/P8MdzzlFtng> and I
am still getting my head around the Gremlin Machine
<https://tinkerpop.apache.org/gremlin.html> (for those interested, I find
the comparison table of the first chapter
<https://www.datastax.com/dev/blog/the-benefits-of-the-gremlin-graph-traversal-machine>
and introduction of their paper <https://arxiv.org/pdf/1508.03843.pdf> some
real eye opener). Also learning their more than 70 predefined steps
<http://tinkerpop.apache.org/docs/current/reference/#graph-traversal-steps> and
some Groovy to overtake ideas from customized Gremlin DSL steps from other
projects <http://joern.readthedocs.io/en/latest/querying.html>.

Meanwhile, I have been told by a friend that their company would have
problems with the performance of the code model of ODF Toolkit.
I took this as an opportunity to take several actions.
First, before talking about performance we need to establish a performance
benchmark.
I found as part of the OpenJDK the Java Microbenchmark Harness (JMH)
<http://openjdk.java.net/projects/code-tools/jmh/> written by the Java
Virtual Machine developers. Nicely described
<http://tutorials.jenkov.com/java-performance/jmh.html> by Jakob Jenkow -
(you might want to read his full performance tutorial). Initialized by
Maven, I have added a benchmark subproject to the toolkit in my current
github code-generation branch
<https://github.com/svanteschubert/odftoolkit/tree/code-generation/benchmark>
on github while the svn2git transition is ongoing
<https://issues.apache.org/jira/browse/INFRA-15596>.

My guess was that ODFDOM is currently using too many classes and
instantiation is slowing things down. For example, JAXB is using fewer
classes.
Therefore, I desired a comparison of ODF 1.2 generated by latest JAXB
release <https://github.com/javaee/jaxb-v2> and our ODFDOM sources.
Due to some problems of endorsing the latest JAXB release (likely due to
enabled JDK 9 modularization), I have just tested the stable

   - JAXB of last Oracle JDK 8 of version 2.2.8-b130911.1802
   - JAXB of last Oracle JDK 9 of version 2.3.0-b170531.0717

As JAXB usually works only with W3C Schema, I tried to transform the ODF
1.2 RelaxNG to W3C schema using James Clark latest Trang
<https://github.com/relaxng/jing-trang>, which worked better than the
experimental -relaxng JAXB command line option of JDK8, which vanished in
JDK9.
But I was not able to switch to XML Schema 1.1 support within JAXB to let
the Unique Particle Attribution problem
<https://en.wikipedia.org/wiki/Unique_Particle_Attribution> vanish and
after many manual W3C schema fixes there were still dozen of duplicated
namings as elements and attributes are used as Java Bean properties only
with their local names.

Anyway, I finally dropped that approach and I am going to test now instead
a W3C schema file, that is usable by JAXB and is as well loadable by our
MultiSchemaValidator. Comparing those two bindings instead.
In addition, there are related XML bindings (ie. X-Stream with existing JMH
approach <http://x-stream.github.io/benchmarks.html>) we could learn from.

Worth to mention in regard to JAXB that in JDK 9 the JAXB package is marked
as deprecated
<https://docs.oracle.com/javase/9/docs/api/index.html?java.xml.bind-summary.html>
.
Nevertheless, I will evaluate if and how the JAXB annotations for
customizing Java program elements to XML Schema mapping </> might be reused.
(For those curious, here some nice quick overview how the JAXB mapping of
W3C schema to Java classes works
<https://docs.oracle.com/cd/E17802_01/webservices/webservices/docs/1.5/tutorial/doc/JAXBUsing2.html#wp99731>
.)

If you are curious, just drop a question and/or provide some feed-back!

Cheers,
Svante

ᐧ