Damjan, I am not digging into the details of how one might do a top-down conversion to an AOO4J.
However, there are bidirectional dependencies that have to be accounted for when Java is on top of native GUI-using and exception-generating code. In my one adventure into JNI, <http://odma.info/dev/devNotes/2007/07/d070701.htm>, I discovered how upward native dependencies matter when the native code presents a modal dialog against the native Window that the Java level creates and uses. I suspect that is a far more elaborate problem in the case of an AOO4J. (I also never passed up an exception or produced a null result.) Since the top-down method that is proposed would require working against the Apache OpenOffice source, I would recommend the following 1. A proof-of-concept be undertaken on a parallel section of the SVN, at <https://svn.apache.org/repos/asf/openoffice/>. (It is more than a branch, it seems to me.) 2. The proof-of-concept should somehow provide adequate functionality to demonstrate that all cases of OpenOffice functionality can be accommodated. There needs to be confidence in such an outcome. 3. The proof-of-concept must extend all the way to deployment and how deployment of released binaries would be undertaken. This also must address localization and QA in some manner. 4. The idea is to identify everything that needs to be accounted for in making such a conversion, and to expose any show-stoppers as early as possible. 5. Working on the proof-of-concept must not extend the critical path for maintenance and release of software on the current AOO 4.x line. This is perhaps the single most-critical requirement. The actual determination to pursue farther would be a matter for the Project Management Committee and the AOO developer community to work out as a matter of project governance. That is not on the table at the moment. I suggest that the question not be entertained in the absence of a proof-of-concept around which there is confidence that all considerations can be addressed. - Dennis > -----Original Message----- > From: Damjan Jovanovic [mailto:dam...@apache.org] > Sent: Sunday, November 8, 2015 00:58 > To: Apache OO <dev@openoffice.apache.org> > Subject: Re: [QUESTION] Getting to AOO for Java (AOO4J)? > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
