This was discussed several times before.
I was initially against the idea as Java can call C++ code easily these
days (eg. JNA, BridJ), but changed my mind when I realized how developing
OpenOffice itself in C/C++ is very difficult, and how much effort is wasted
(portability (eg. Win64), problematic build systems, security issues,
crashes) all because of C/C++.
But even at a rate of rewriting 1000 lines per day in Java, it would take
10000 days, which is about 28 man years, to rewrite OpenOffice's 10 million
lines of code...
I have been developing a compiler to automatically convert C++ to Java,
which should help. It will only supports a high-level subset of C++ and
won't convert all C++ code (no void pointers, no casts between object
pointers not in a class hierarchy, no casts between integer pointer types,
no raw memory access with memcpy() and the like). But what it does convert,
it will convert into beautiful, readable, maintainable, clear Java code
that is often of higher quality than the original C++ code was. It's still
in early stages and only converts basic types and operators on them, and
the if/for/return statements at the moment, there no
pointers/references/arrays/classes/enums/etc. yet. Preprocessor macros also
get inlined :-(.
Even when this compiler is finished though, 10 million lines won't be
converted overnight. It will still be a long slow process, with manual
review, and rewriting low-level code that uses void pointers etc. And if
Java becomes a mandatory dependency for OpenOffice, the current Java
support in OpenOffice has to be vastly improved. We either have to compile
Java modules into native code so that no JRE is necessary, ship with a JRE
(which can't be Oracle's JRE or OpenJDK's, since it's copyleft), or
automatically download and install a JRE ourselves at startup - the current
solution of an optional JRE you configure through the options menu won't
There is also the question of how best to port. We could gradually convert
the current codebase from the inside, presumably initially taking small,
preferably already optional, non-UI, non-localisable, and preferably
already problematic - modules - that are only accessed via UNO, and
reimplementing them in Java, which is a first-class UNO language.
Alternatively we could start a new project, and port useful bits of code to
it, while redeveloping others. Given the vast amount of infrastructure in
the project - UNO, documentation generators, localization code - and the
amount that has to be ported to become useful - only the former approach
I think the next step is to find a good first module to port, as that can
also help guide further compiler development.
On Fri, Oct 14, 2016 at 12:24 PM, <iamsuhailans...@gmail.com> wrote:
> I have a suggestion that Apache should write OpenOffice using Java and
> Netbeans platform.
> Sent from Mail for Windows 10