openoffice programming

[ia...@gmail.com]

I have a suggestion that Apache should write OpenOffice using Java and Netbeans platform. 

Sent from Mail for Windows 10

Re: openoffice programming

[Peter Kovacs <le...@gmail.com>]

   Instead of Languages I rather would like to discuss overall 
architecture. The initial Architecture has not been changed much since 
it was introduced i think.
But over time the requirements I see in the code have changed. Solving 
Requirements with code and without adjusting the architecture leads to a 
certain maintainability decay.

I.E. it looks to me that at first the sw had a document class, and was a 
simple writing app. Then someone had the Idea that features he needed in 
writer, he could use in tables too.
So the UNO Idea was born. But this new feature was only attached to the 
existing architecture. And because Java was the cool thing of its time 
they used it.
Please this is no critic or complain. Just the way I think  the code 
might become what it is today. these things are normal. I see it every day.

For the existing architecture the central thing is in my opinion the 
"framework".
Which melts the document together with the GUI, by using UNO 
architecture. (roughly, may be wrong)
It has various concepts doubled, or distributed through the code. trying 
to package funcionality into small modular "services"


I want to plead for a more natural abstract Architecture approach. Which 
is Modular on a greaterscale, to provide orientation. And being Modular 
on small scale to be as much as possible stay generic. In between we 
need to be concrete and descriptive.

The Core piece for me for a futer possible architecture is an 
UNO::Document. The UNO::Document represents an Abstract view of a 
Document and its components.
And it delivers One Memory implementation for the structure the user 
works on.
That would be for me in a  (not comlete) list:
  # tables
  # paragraph (text)
  # Linked Lists
  # Pictures
  # grahical Items
  # Indexes
  # documents
  # formdefinition
  # Layouts
Which offers one abstract implementation independant of the target 
program (writer, tables, math, base).
Plus haveing one Interface to Manipulate and tracks Manipulations of 
these elements.

Gathering all GUI stuff into a Control Architecture. So we can Produce 
the (G)UI want. (MVC or MV are one of the Buzzwords I think of)
This part can focus on its usage like classic office apps, document 
fabric service, online service, or what else we want to add.
I advise to move over to use Vulcan, HeavyMetal and/or OpenGL as 
graphical render languages in the long run. This might seem to shoot 
with cannons on birds,
but to be honest, modern PC Architecture is based on GPUs and multi 
purpose CPUs, and it is stupid not to use both to show stuff. Makes live 
so much easier, the GPUs do take care of all the stuff we want.
Also Android or iOS architecture can be targeted if we do it right, 
without a big fuzz. However we need to think differently user experience 
on those devices. I think with a Office renderengine we can focus on
this.

Also we should cluster Importers/Exporters into one set. OOXML and 
ODFormat is the same XML Idea.
There should not be the trouble of inventing the wheel all over it again 
and again.
Also data connectivity should be placed here. There should be One 
approach to access or write to Disk, cloud, internet, database.
I would prefer Java here, since it is quite capable of handling XML, 
internet, db and data streams.
Maybe not obvious that I see a database here. For me a DB is never a 
Frontend, only a backend tool. OO is to me a clear Frontend tool.

I would like to cluster is to have One MacroInterface where all 
Languages can attach to.

The only thing this Architecture might be difficult are Extentions. We 
need to think how this has to be handled. Especially with the existing 
stuff around.

I think this aproach is easy to understand even for starters, compared 
to the Architecture currently used. If you think on the details just 
think of components you would expect to drill down in this section.
Also we could start with only clustering the existing code, so we know 
what we look at. I think current Architecture does feature some of the 
layout at least a bit. Then start slowly to change code to honor the 
target architecture more and more. In total I think maybe a bit naive, 
that this way is do able without the need to do it all in one step, and 
beeing able to iterate at a speed we manage.

I want to add I am not completly sure about the current architecture. So 
if I am wrong and my understanding is frawed, please take my apologies.
I wrote the mail because I do not believe in language discussions 
without haveing a architecture discussion first. And so I bring it on 
the table with the preperation state I am in.
It is better to have a bad start then to miss the discussion.
I rather would have liked to check more on current code befor makeing 
proposals which are based upon the Idea what I would like to have in 
order to guide me.

In the end I think even if you like the approach this can only the start 
of an architectural discussion. If you do not like the approach we need 
to sample the arguments and find a structure o g for.
I am not fixed on this approach. It is only what I think of if I 
brainstorm a bit what components I would cluster in.

All the best
Peter

On 14.10.2016 18:01, Damjan Jovanovic wrote:
> 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
> fly.
>
> 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
> seems feasible.
>
> I think the next step is to find a good first module to port, as that can
> also help guide further compiler development.
>
> Damjan
>
> On Fri, Oct 14, 2016 at 12:24 PM,<ia...@gmail.com>  wrote:
>
>> I have a suggestion that Apache should write OpenOffice using Java and
>> Netbeans platform.
>>
>> Sent from Mail for Windows 10
>>
>>

Re: openoffice programming

[Andrew Douglas Pitonyak <an...@pitonyak.org>]

On 10/15/2016 10:17 AM, Alex Suk wrote:
> Damjan Jovanovic wrote
>> 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...
> Do 10M lines in C++ convert to 10M lines in Java? Is it a 1:1 conversion?

An automated transformation will almost always be close to a 1:1 
conversion because that is easier to do.

Regardless, it is a tricky business and difficult to get it right. It is 
difficult to do the conversion, and even the clean-up after the 
conversion is tricky business.

> Are there successful examples similar in magnitude to AOO in the software
> world of such code rewrites from language A to language B? How did they make
> it?
> Is it possible to reduce the 10M lines for conversion by for example
> omitting Draw and Base from the suite?
> Can this conversion be performed in a modular way?
> Many thanks for answering.

-- 
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info:  http://www.pitonyak.org/oo.php


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: openoffice programming

[Damjan Jovanovic <da...@apache.org>]

On Sat, Oct 15, 2016 at 4:17 PM, Alex Suk <es...@gmail.com> wrote:

> Damjan Jovanovic wrote
> > 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 am no programmer but this is very interesting!
> Do 10M lines in C++ convert to 10M lines in Java? Is it a 1:1 conversion?
> Are there successful examples similar in magnitude to AOO in the software
> world of such code rewrites from language A to language B? How did they
> make
> it?
> Is it possible to reduce the 10M lines for conversion by for example
> omitting Draw and Base from the suite?
> Can this conversion be performed in a modular way?
> Many thanks for answering.
>
>
Some language constructs only allow 1 expression. For example both C++ and
Java require 1 expression as the while loop condition. If the conversion
generated more expressions in Java than there were in C++, there would be
the serious issue of having to modify surrounding code to evaluate these
expressions, so their results can combine into 1 while loop condition
expression.

There are places where Java must use multiple expressions where C++ had 1,
for example because Java's bit shift operators on int only shift by the
lowest 5 bits, while C++'s shift by the entire value (it's "undefined
behaviour" to shift beyond the first operand size according to the
specification, but I follow actual GCC and Clang behaviour on amd64). So 1
<< 128 overflows to 0 in C++, but remains 1 in Java.
 x << y in C++ would have to translate into this in Java:
(y & ~0x1f) == 0 ? (x << y) : 0
which can't be done like that, as y is evaluated twice, with potential side
effects: if the expression was 5 << i++, i would be incremented twice. We
thus have to make a copy of y and evaluate the copy. This would be an extra
statement that has to be added somewhere. So far I've dealt with that by
compiling such expressions into calls to helper methods like
Integers.shiftLeft(), which make copies of the parameters and operate on
those copies, thus keeping the conversion 1:1.

I am not sure what can be omitted. After all you can draw in a spreadsheet,
and you can import database data.

Yes, at least some of the conversion could be done module-at-a-time for
modules that are only accessed through UNO.

Damjan

Re: openoffice programming

[Alex Suk <es...@gmail.com>]

Damjan Jovanovic wrote
> 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 am no programmer but this is very interesting!
Do 10M lines in C++ convert to 10M lines in Java? Is it a 1:1 conversion?
Are there successful examples similar in magnitude to AOO in the software
world of such code rewrites from language A to language B? How did they make
it?
Is it possible to reduce the 10M lines for conversion by for example
omitting Draw and Base from the suite?
Can this conversion be performed in a modular way? 
Many thanks for answering.



--
View this message in context: http://openoffice.2283327.n4.nabble.com/openoffice-programming-tp4683649p4683681.html
Sent from the Development mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: openoffice programming

[Damjan Jovanovic <da...@apache.org>]

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

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
seems feasible.

I think the next step is to find a good first module to port, as that can
also help guide further compiler development.

Damjan

On Fri, Oct 14, 2016 at 12:24 PM, <ia...@gmail.com> wrote:

> I have a suggestion that Apache should write OpenOffice using Java and
> Netbeans platform.
>
> Sent from Mail for Windows 10
>
>

Re: openoffice programming

[Patricia Shanahan <pa...@acm.org>]

On 10/14/2016 3:24 AM, iamsuhailansari@gmail.com wrote:
> I have a suggestion that Apache should write OpenOffice using Java and Netbeans platform.

Thanks for your suggestion.

There would certainly be major advantages to it being in Java. We could
do a single build for all platforms. Several forms of error that we
encounter in the C++ code are impossible in Java.

Personally, I prefer Eclipse to Netbeans for my Java programming, but
that is a detail.

The obvious problem is that Apache OpenOffice is a very large program,
developed over many years by, at times, large teams of full time
programmers. I suggest fleshing out your suggestion with your analysis
of the resources required, especially the amount of programming time,
and ideas for obtaining that much programming effort.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: openoffice programming

["Simon P. Lucy" <si...@gmail.com>]

If you seriously want to redevelop OO then you need to rearchitect and
replace in an incremental fashion.
Don't try and convert code or even translate, instead concentrate on the
features and replace using a micro architecture.

S

On 14 Oct 2016 12:48, <ia...@gmail.com> wrote:

> I have a suggestion that Apache should write OpenOffice using Java and
> Netbeans platform.
>
> Sent from Mail for Windows 10
>
>