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 > >
