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 (https://github.com/nativelibs4java/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
Windows...
I only consider the port to Java feasible because it could be mostly
automated. A while ago I discovered cpp-to-java-source-converter (
https://github.com/danfickle/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 (
https://github.com/DamjanJovanovic/cpp-to-java-source-converter) 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.
Damjan
On Sat, Nov 7, 2015 at 9:41 PM, Dennis E. Hamilton <orc...@apache.org>
wrote:
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
ODF
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 [mailto:orc...@apache.org]
Sent: Tuesday, October 20, 2015 15:36
To: dev@openoffice.apache.org
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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
