Re: [QUESTION] Getting to AOO for Java (AOO4J)?

[Andrew Rist]

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

RE: [QUESTION] Getting to AOO for Java (AOO4J)?

[Dennis E. Hamilton]

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 

RE: [QUESTION] Getting to AOO for Java (AOO4J)?

[Dennis E. Hamilton]

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

[Damjan Jovanovic]

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

[toki]

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

[Fernando Cassia]

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

[Andrea Pescetti]

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

[Damjan Jovanovic]

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 

Re: [QUESTION] Getting to AOO for Java (AOO4J)?

[#PATHANGI JANARDHANAN JATINSHRAVAN#]

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

[Patricia Shanahan]

"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)?

[toki]

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

[Kay Schenk]

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

[Patricia Shanahan]

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

[Patricia Shanahan]

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 

Re: [QUESTION] Getting to AOO for Java (AOO4J)?

[Marcus]

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

[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

RE: [QUESTION] Getting to AOO for Java (AOO4J)?

[Dennis E. Hamilton]

+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)?

[Patricia Shanahan]

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