openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <>
Subject Re: [QUESTION] Getting to AOO for Java (AOO4J)?
Date Sun, 08 Nov 2015 08:58:06 GMT
Let's examine porting AOO to Java in more detail.

Java can easily call C code with JNA and also easily call even C++ with
BridJ ( (with its sister project
JNAerator even generating Java code to compile/link yours against by
examining C/C++ header files), and Java can easily call any UNO component.
C/C++ on the other hand can only call Java with great pain using the Java
invocation API, but UNO wraps that for us, so a Java component can be
called as easily as any UNO component. So ideally the smallest unit of
granularity while converting should be an UNO component, and C++ -> Java
call flow should be avoided.

The easiest way to avoid C++ -> Java calls is to convert top down, starting
with top level modules like main/desktop and working down. But if A uses B,
and A is ported to Java and calls B using JNA/BridJ, then when B is also
ported to Java, A's calls to B need to be ported from JNA/BridJ to pure
Java, so working top down, while easier, means a 2 phase porting process is
necessary. Porting modules that are only accessed via UNO, would avoid the
2 phase problem as UNO would be used before and after; main/xmlsecurity
which is only accessed via UNO and needs the category B nss library, is on
the chopping block :-).

The how of porting is maybe the most interesting. For the migration from
CppUnit to Google Test I did recently, the only reason I finished such a
massive undertaking in the time that I did, is that I quickly developed a
tool to parse source code and convert the API. The tens of thousands of
calls to CPPUNIT_ASSERT* in our source tree didn't require hundreds of
thousands of keystrokes. Most of my time was spent on the stuff that
couldn't be automated, like migrating makefiles, fixing failing tests, and
hooking the tests into the build. My migration attempt from dmake to gbuild
- 100% manually - has been a disaster by comparison: only main/formula was
migrated so far - even the tiny 4 file main/animations module mysteriously
crashes Impress when ported, and 1 test in main/tools doesn't link on

I only consider the port to Java feasible because it could be mostly
automated. A while ago I discovered cpp-to-java-source-converter (, a compiler that
converts C++ to Java. It's written in Java, under the ASLv2. It uses the
C++ parser from the Eclipse CDT project. It's still incomplete, very slow,
full of errors, and it produces Java code even more complex than the C++
was. But I played with it, fixed a few bugs, forked it ( and am
working on more improvements. And with some further work, I think it has
real potential. Obviously not all C++ code can be converted to Java: goto
statements, iterating a char pointer over a struct, and so on, but those
are rare and can always be converted manually. But for the rest, and with
some improvements to cpp-to-java-source-converter, the Java code produced
could be of very high quality: elimination of destructors that only release
memory, the rest converted to close() and RAII implemented as Java 7's
try-with-resources, pointer iteration converted to indexing or Java
iterators and possibly the enhanced for loop, etc.

Also cpp-to-java-source-converter could be patched to output JNA or BridJ
calls from the converted Java, and maybe to even do some API remapping in
place of calls to C++ APIs, like change ::std::map to java.util.Map.

Of course, it won't all be that easy: comments in the code would have to be
copied to Java manually (and hopefully translated from German),
preprocessor #define constants need research, some C++ idioms will be slow
in Java and need to be rewritten, etc. But I am hopeful that this is still
the most promising path, which will produce the highest quality Java code
in the shortest amount of time.

Even if the goal is 100% Java, there would still be a long transition
period where we use C++ as well. We should also improve the user experience
with Java before porting anything to Java. Then maybe we should start by
porting the dodgy modules like xmlsecurity.


On Sat, Nov 7, 2015 at 9:41 PM, Dennis E. Hamilton <>

> There has been suggestion, and some expressed support, for AOO becoming a
> Java application.
> I don't want to discuss the merits of this, but how it might be undertaken.
>  1. NO STANDING-STILL ASSUMPTION. My first assumption is that one can't
> cease Apache OpenOffice maintenance and support while something like a
> redevelopment on Java occurs. It is pretty unthinkable that development of
> a
> Java version can be accomplished inside the release cycle (even the past
> lengthy cycle), and that migration from AOO as we know it can't be done
> like
> throwing a switch on the universe.  So, my first assumption, which one can
> challenge, is that any development of a Java version must happen separate
> from the ongoing support for the current AOO.
>  2. FORKING TO MAKE AOO4J?  One could consider making a project fork.  That
> doesn't make sense as an Apache project, going through incubation, having
> to
> do much from scratch.  But one could make an independent fork of a
> Java-based AOO (near) workalike. It could be a GitHub project, for example.
> If it is to come back to Apache, it must be sort of managed as an Apache
> Project from the beginning, especially around license and code provenance
> (IP) considerations.  That might be too hard.
>  3. EXPANDING THE ODF TOOLKIT PROJECT.  This is my favorite.  The Apache
> Toolkit (incubating) project is Java-based already.  It deals with some
> fundamentals about supporting the OpenDocument Format (ODF).  One could
> imagine building up the modularization to the point where one could achieve
> Writer, Calc, ... etc., workalikes.  There, AOO4J could be a demonstration
> of composition of a suite (or even standalone components with shared
> libraries).  There are also available related applications for
> interoperability testing of the level of ODF support: Apache OpenOffice
> itself, LibreOffice, and Microsoft Office.  The support for Microsoft
> Office
> native formats could come from the POI projects and other open-source
> resources.
> The test of capacity is then one of how (2) or (3) manages to grow into a
> thriving project.  Meanwhile, AOO is sustained and there are no diversions
> until a natural migration occurs.
> How does any of that sound.  It means that there would be no revolutionary
> disruption of the Apache OpenOffice project itself.
>  - Dennis
> > -----Original Message-----
> > From: Dennis E. Hamilton []
> > Sent: Tuesday, October 20, 2015 15:36
> > To:
> > Subject: RE: [QUESTION] Optional Java Use for Essential Functionality
> >
> > Summary of what this thread revealed, in-line.
> >
> [ ... ]
> > [orcmid] There were some unexpected responses to these questions.
> >
> >  2. One suggestion was to remove the dependencies on Java.
> >
> >  3. Other suggestions included increasing the dependencies on Java,
> > perhaps
> > going so far as to make AOO a Java application.
> >
> [ ... ]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message