Re: [QUESTION] Getting to AOO for Java (AOO4J)?
Hope this is not off topic, but I think it should be a part of this conversation. If w are looking at moving AOO forward, then we should be looking forward and not just porting to another development platform. As such, the two most important destinations are a cloud implementation and collaboration. I do think java (plus javascript on a browser on the client) is the best way to move in that direction, and the first step would be to port AOO (or at least large portions) to java. Of course, this project would be an order of magnitude harder than just porting, but it is the way we could move forward, and not just provide another port of the current product. A. On 11/15/2015 12:06 PM, Dennis E. Hamilton wrote: > 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 >> 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, th
Re: [QUESTION] Getting to AOO for Java (AOO4J)?
On Mon, Nov 16, 2015 at 2:10 AM, toki wrote: > On 15/11/2015 20:06, Dennis E. Hamilton wrote: > > > Please be more specific. I can't tell from the previous post what you > mean by deserializing untrusted code. > > There are a string of known zero day exploits that Oracle, for whatever > reason, has not released patches for, despite exploits having been in > the wild for more than 90 days. > > jonathon > > > You really seem to have it in for Java, and would have us reject the entire platform for all eternity because of the alleged current state of 1 implementation. What, then, is your rationale for remaining with C/C++, which are insecure by design in all compilers AOO ever used (eg. no arrays bounds checking, printf doesn't verify types), or what alternative do you propose instead? Damjan
Re: [QUESTION] Getting to AOO for Java (AOO4J)?
On 15/11/2015 20:06, Dennis E. Hamilton wrote: > Please be more specific. I can't tell from the previous post what you mean > by deserializing untrusted code. There are a string of known zero day exploits that Oracle, for whatever reason, has not released patches for, despite exploits having been in the wild for more than 90 days. jonathon signature.asc Description: OpenPGP digital signature
RE: [QUESTION] Getting to AOO for Java (AOO4J)?
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 > 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
RE: [QUESTION] Getting to AOO for Java (AOO4J)?
Patricia: > -Original Message- > From: Patricia Shanahan [mailto:p...@acm.org] > Sent: Sunday, November 8, 2015 11:46 > To: dev@openoffice.apache.org > Subject: Re: [QUESTION] Getting to AOO for Java (AOO4J)? > > I would be strongly opposed to deserializing untrusted code - it is full > of problems. [orcmid] Please be more specific. I can't tell from the previous post what you mean by deserializing untrusted code. > > On 11/8/2015 11:14 AM, toki wrote: > > On 08/11/2015 14:32, Patricia Shanahan wrote: > > > >> I am just getting started on AOO, and don't know the history of this > > discussion, > > > > Pretty much since Sun purchased StarWriter, there have been proposals > to > > make OpenOffice.org Java only. If one considers NeoOffice to be a Java > > fork, then it is the only proposal to have gained any traction. > > > >> but here are some general advantages of Java: > > > > Things such as > > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere- > jboss-jenkins-opennms-and-your-application-have-in-common-this- > vulnerability/ > > are viewed as sufficient reason to avoid Java wherever and whenever > > possible. > > > > FWIW, that isn't the only list of known, unpatched zero day exploits > of > > Java, that are in the wild. > > > > jonathon > > > > > > > > - > 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
Re: [QUESTION] Getting to AOO for Java (AOO4J)?
I would be strongly opposed to deserializing untrusted code - it is full of problems. On 11/8/2015 11:14 AM, toki wrote: On 08/11/2015 14:32, Patricia Shanahan wrote: I am just getting started on AOO, and don't know the history of this discussion, Pretty much since Sun purchased StarWriter, there have been proposals to make OpenOffice.org Java only. If one considers NeoOffice to be a Java fork, then it is the only proposal to have gained any traction. but here are some general advantages of Java: Things such as http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ are viewed as sufficient reason to avoid Java wherever and whenever possible. FWIW, that isn't the only list of known, unpatched zero day exploits of Java, that are in the wild. jonathon - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [QUESTION] Getting to AOO for Java (AOO4J)?
On 08/11/2015 14:32, Patricia Shanahan wrote: >I am just getting started on AOO, and don't know the history of this discussion, Pretty much since Sun purchased StarWriter, there have been proposals to make OpenOffice.org Java only. If one considers NeoOffice to be a Java fork, then it is the only proposal to have gained any traction. >but here are some general advantages of Java: Things such as http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ are viewed as sufficient reason to avoid Java wherever and whenever possible. FWIW, that isn't the only list of known, unpatched zero day exploits of Java, that are in the wild. jonathon signature.asc Description: OpenPGP digital signature
Re: [QUESTION] Getting to AOO for Java (AOO4J)?
On 11/08/2015 05:19 AM, #PATHANGI JANARDHANAN JATINSHRAVAN# wrote: > Hi, I am pretty much a noob and have only started out > contributing, but may I ask why moving to Java from C++ is being > considered? This migration will take effort and time, and I was > of the understanding that C++ code runs faster than Java. > > Thanks Jatin I am also wondering about end user memory requirements with a Java move. See: http://www.openoffice.org/dev_docs/source/sys_reqs_aoo41.html for our current System Requirements. In my experience, fine tuning a JVM to work properly for whatever it is you're doing has been VERY tricky. I don't disagree that moving to Java would simplify some our maintenance aspects, but I'm generally concerned about performance in this kind of environment. > > > > On 11/8/15, 8:48 PM, "Fernando Cassia" > wrote: > >> On Sat, Nov 7, 2015 at 4:41 PM, Dennis E. Hamilton >> wrote: >> >>> There has been suggestion, and some expressed support, for >>> AOO becoming a Java application. >>> >> >> +1 I think it would be nice. Previous work on Java based office >> suites show promise and that this is possible. >> >> Cases in point: >> >> 1. ThinkFree Office >> https://en.wikipedia.org/wiki/ThinkFree_Office >> http://www.linuxplanet.com/linuxplanet/reviews/1579/1/ (the >> biggest annoyance back when I tried it were jagged fonts, but >> the Java platform has gained support for font hinting in later >> releases and even HiDPI fonts in Java9). >> >> 2. JoeOffice >> http://www.infoworld.com/article/2614544/office-software/java-developer-says-he-built--launched-basic-open-source-office-suite-in-30-days.html >> >> Promising work, based on the Netbeans Platform. >> >> 3.xfy (now: xMetal) >> http://www.infoworld.com/article/2671944/application-development/reinventing-the-office-suite.html >> >> >> Never tried it, but the above article makes some good points. >> >> >>> >>> 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. >>> >> >> Of course not, Still, the umbrella AOO project can produce and >> DOES produce AOO for several platforms, right, well, Java is a >> platform too. "AOO for Java" or "AOO Java" sounds about right. >> Independent of work on the C/C++ codebase. >> >> >>> 2. FORKING TO MAKE AOO4J? One could consider making a >>> project fork. >>> >> >> The word "fork" only has negative connotations and very little >> positives, if you ask me. Think about all the negative >> headlines that could be written with that word. >> >> No thanks, I prefer "AOO extended to support Java" (AOO for >> Java or AOO Java). >> >> Remember that "Open Office" (the brand name recognition / >> mindshare) is AOO's main asset. Even if you guys re-released >> "Joe's Office" with an Apache Open Office brand name attached >> to it, I bet you would get 10x more users than whatever "Joe's >> Office" was able to achieve. ;) >> >> Why not join forces and invite the "Joe's Office" developer to >> such a project? Just thinking aloud. >> >> Just my $0.02 FC > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > -- MzK “Somebody's gotta win, somebody's gotta lose. Just don't fight about it. Just try to get better." -- Yogi Berra - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [QUESTION] Getting to AOO for Java (AOO4J)?
On 07/11/2015 Marcus wrote: All nice, but with a short of developers that could do any of the points you listed below, it's just a theoretical idea what could be done. ;-) While Damjan brought a somewhat more pragmatic approach here, I'm still skeptical: not even coming to whether it is desirable, a Java port is unrealistic at the moment. Sure, automation can help, but our usage of C++, with proliferation of types, exceptions used for non-exceptional control flow and many other issues that could be listed makes it hard to rely on a "standard" transformation tool: at least we would need a huge investment on tests. This doesn't mean that developers who love Java don't have anything to do in OpenOffice! Completing Andre's unfinished work on the new Java-based OOXML import/export framework would be a spectacular asset that a large percentage of people would benefit from. Ask for pointers/history if interested: there are wiki pages, issues and code, but it may be hard to find out what refers to the new project and what refers to the existing read-only implementation. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [QUESTION] Getting to AOO for Java (AOO4J)?
"C++ code runs faster than Java" is, to some extent, a hold-over from the early days of Java, when JVMs where pure Bytecode interpreters. These days, it gets compiled, and optimized, as it is running. The optimizer has more data than a C++ optimizer, because it can see what flows are being used in that workload on that day. If I were writing a straightforward number-crunching program like a linear equation solver I would probably write it in Fortran or C++, not Java, but that is not the sort of program we are talking about here. I am just getting started on AOO, and don't know the history of this discussion, but here are some general advantages of Java: * No pointer arithmetic. Java "references", which are either null or a pointer to an object, are not subject to any direct arithmetic. Everything done with them is checked to ensure they always point to an object of appropriate class for the type of the pointer. If you see a java.lang.String reference it is either null or points to a String object. * Every array carries around with it its size information, and all array accesses are checked to ensure they are accessing into the array, not before it or after it. No buffer overflow. * Automatic garbage collection. Memory management is just a matter of making sure each component only keeps references to objects it is going to need in the future. This is actually what switched me from C++ to Java. I was working on performance models of large servers. I needed to keep the object representing e.g. a cache miss around until both address path and data path operations were complete, and either could finish first. My C++ program worked, but I had put a lot of thought into memory management. The next system I worked on I modeled in Java. I spent practically no time and smartness cycles on memory management. In general, my experience is that it is easier to get to a solidly working program in Java than C++, easier to localize bugs, and easier to make changes safely. That ease of programming translates into easier changes in algorithms and data structures, and those are the changes that bring the really big performance wins for more complicated programs. If we were starting from scratch, with no existing code, and discussing the choice of language for AOO I would be pushing extremely strongly for Java. As it is, you have a valid point about the effort and time for migration, which has to be traded off against the benefits. Patricia On 11/8/2015 5:19 AM, #PATHANGI JANARDHANAN JATINSHRAVAN# wrote: Hi, I am pretty much a noob and have only started out contributing, but may I ask why moving to Java from C++ is being considered? This migration will take effort and time, and I was of the understanding that C++ code runs faster than Java. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [QUESTION] Getting to AOO for Java (AOO4J)?
Hi, I am pretty much a noob and have only started out contributing, but may I ask why moving to Java from C++ is being considered? This migration will take effort and time, and I was of the understanding that C++ code runs faster than Java. Thanks Jatin On 11/8/15, 8:48 PM, "Fernando Cassia" wrote: >On Sat, Nov 7, 2015 at 4:41 PM, Dennis E. Hamilton >wrote: > >> There has been suggestion, and some expressed support, for AOO becoming a >> Java application. >> > >+1 I think it would be nice. Previous work on Java based office suites show >promise and that this is possible. > >Cases in point: > >1. ThinkFree Office >https://en.wikipedia.org/wiki/ThinkFree_Office >http://www.linuxplanet.com/linuxplanet/reviews/1579/1/ >(the biggest annoyance back when I tried it were jagged fonts, but the Java >platform has gained support for font hinting in later releases and even >HiDPI fonts in Java9). > >2. JoeOffice >http://www.infoworld.com/article/2614544/office-software/java-developer-says-he-built--launched-basic-open-source-office-suite-in-30-days.html >Promising work, based on the Netbeans Platform. > >3.xfy (now: xMetal) >http://www.infoworld.com/article/2671944/application-development/reinventing-the-office-suite.html > >Never tried it, but the above article makes some good points. > > >> >> 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. >> > >Of course not, Still, the umbrella AOO project can produce and DOES produce >AOO for several platforms, right, well, Java is a platform too. >"AOO for Java" or "AOO Java" sounds about right. Independent of work on the >C/C++ codebase. > > >>2. FORKING TO MAKE AOO4J? One could consider making a project fork. >> > >The word "fork" only has negative connotations and very little positives, >if you ask me. Think about all the negative headlines that could be written >with that word. > >No thanks, I prefer "AOO extended to support Java" (AOO for Java or AOO >Java). > >Remember that "Open Office" (the brand name recognition / mindshare) is >AOO's main asset. Even if you guys re-released "Joe's Office" with an >Apache Open Office brand name attached to it, I bet you would get 10x more >users than whatever "Joe's Office" was able to achieve. ;) > >Why not join forces and invite the "Joe's Office" developer to such a >project? Just thinking aloud. > >Just my $0.02 >FC - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [QUESTION] Getting to AOO for Java (AOO4J)?
On Sat, Nov 7, 2015 at 4:41 PM, Dennis E. Hamilton wrote: > There has been suggestion, and some expressed support, for AOO becoming a > Java application. > +1 I think it would be nice. Previous work on Java based office suites show promise and that this is possible. Cases in point: 1. ThinkFree Office https://en.wikipedia.org/wiki/ThinkFree_Office http://www.linuxplanet.com/linuxplanet/reviews/1579/1/ (the biggest annoyance back when I tried it were jagged fonts, but the Java platform has gained support for font hinting in later releases and even HiDPI fonts in Java9). 2. JoeOffice http://www.infoworld.com/article/2614544/office-software/java-developer-says-he-built--launched-basic-open-source-office-suite-in-30-days.html Promising work, based on the Netbeans Platform. 3.xfy (now: xMetal) http://www.infoworld.com/article/2671944/application-development/reinventing-the-office-suite.html Never tried it, but the above article makes some good points. > > 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. > Of course not, Still, the umbrella AOO project can produce and DOES produce AOO for several platforms, right, well, Java is a platform too. "AOO for Java" or "AOO Java" sounds about right. Independent of work on the C/C++ codebase. >2. FORKING TO MAKE AOO4J? One could consider making a project fork. > The word "fork" only has negative connotations and very little positives, if you ask me. Think about all the negative headlines that could be written with that word. No thanks, I prefer "AOO extended to support Java" (AOO for Java or AOO Java). Remember that "Open Office" (the brand name recognition / mindshare) is AOO's main asset. Even if you guys re-released "Joe's Office" with an Apache Open Office brand name attached to it, I bet you would get 10x more users than whatever "Joe's Office" was able to achieve. ;) Why not join forces and invite the "Joe's Office" developer to such a project? Just thinking aloud. Just my $0.02 FC
Re: [QUESTION] Getting to AOO for Java (AOO4J)?
Using some combination of general and special purpose tools to do the bulk of the conversion makes sense to me. In addition, once we have functionally correct Java code, refactoring for maintainability becomes easier. I am most familiar with the tools built into Eclipse: See http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fref-menu-refactor.htm Getting to good quality Java code might require a combination of manually-selected refactoring and tool creation to automate common cases. On 11/8/2015 12:58 AM, Damjan Jovanovic wrote: 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 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
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 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
Re: [QUESTION] Getting to AOO for Java (AOO4J)?
On 11/7/2015 11:41 AM, Dennis E. Hamilton 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. ... 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. For completeness, also consider the following options: * Direct to TLP. The board has approved moving a new project directly to top level project status without going through the incubator. It requires a proposed PMC most of whose members are also ASF members. * Spawn a subproject within AOO. I have followed some of the GitHub discussions on various mailing lists. I think it would be cleaner to keep AOO4J inside Apache and under SVN control. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: [QUESTION] Getting to AOO for Java (AOO4J)?
+1 > -Original Message- > From: Marcus [mailto:marcus.m...@wtnet.de] > Sent: Saturday, November 7, 2015 11:57 > To: dev@openoffice.apache.org > Subject: Re: [QUESTION] Getting to AOO for Java (AOO4J)? > > All nice, but with a short of developers that could do any of the points > you listed below, it's just a theoretical idea what could be done. ;-) > > My 2 ct. > > Marcus [orcmid] I agree completely, Marcus. The whole idea is to get the idea of an AOO4J off the critical-path of AOO work/speculation and let those who are inclined to attempt an AOO4J do their proof-of-concept elsewhere. > > > > Am 11/07/2015 08:41 PM, schrieb 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. [ ... ] > > 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 > > > > > > -- > > Ciao > > Marcus > > - > 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
Re: [QUESTION] Getting to AOO for Java (AOO4J)?
All nice, but with a short of developers that could do any of the points you listed below, it's just a theoretical idea what could be done. ;-) My 2 ct. Marcus Am 11/07/2015 08:41 PM, schrieb 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 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 -- Ciao Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[QUESTION] Getting to AOO for Java (AOO4J)?
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
